Roadmap: How to Adopt the Reviews Practice
This roadmap describes how to adopt the Reviews practice.
Main Description

Getting Started

What are reviews and why use them

Reviews can be conducted in person, by web conference or offline.  In an offline review, the reviewers perform their review in their own time and send comments by email or some other collaborative tool.  Reviews help organizations deliver quality products, identify problems early and help build an image of the product for team members.  When implemented across teams, reviews also provide opportunities for people to discover design and code from other groups, and increase the chances of detecting common source code, reuse opportunities, and opportunities for generalization. Reviews also provide a way to coordinate the architectural style among various groups. The three types of reviews are:

Review Presentation

A meeting at which a work product, or a set of work products are presented to the user, customer, or other interested parties for comments and approval.

Inspection
An evaluation technique in which work products are examined in detail by a person or group other than the author to detect errors, violations of development standards, and other problems.  While using this method, confine attention to at most two aspects.

Walkthrough
A review process in which the review coordinator, in this case also a developer, leads one or more reviewers, possibly members of the development team, through a segment of a work product that he or she has written while the other members ask questions and make comments about technique, style, possible error, violation of development standards, and other problems.

When to perform a review

Review Presentation:

  • Evaluating project progress or project-level plan
  • Monitoring the status of schedules and progress regards to schedule
  • To determine if a product meets specifications and complies to the design

Inspection:

  • Used to identify specific errors or problems

Walkthrough

  • Used to find anomalies
  • Effective form of educating the reviewers, that is, team members and stakeholders


How often are reviews performed

In general, the review process follows a repetitive cycle:

  • An issue is raised by a reviewer.
  • The issue is discussed, and potentially confirmed.
  • A defect is identified (something is identified as needing to be addressed).
  • Continue until no more issues are identified.

In order for this to work effectively, everyone must understand that the goal of a review is to improve the quality of the reviewed work product. The work products should be reviewed with a critical eye to finding problems. Doing this can be difficult, so all reviewers must constantly remind themselves to focus on identifying issues (we are all natural problem solvers, but as reviewers we must put that aside).

We all have strong ownership of our work; it is often difficult to accept criticism, even when it is constructive. As a result, we must work even harder to focus on the goals of the review: to make that work better.

Formality of reviews

Review Levels

Explanation

Comments

Formal-External

This work product is part of the delivery at a specific milestone and requires some form of approval by the customer, the sponsor or some other external stakeholder. The review record is configuration managed along with the work product. 

For example, the Vision and the Business Case are work products that normally have to be reviewed by stakeholders. 

Formal-Internal

This work product is formally reviewed internally by the project. The review record is configuration managed along with the work product.

For example, the interfaces of design subsystems usually have to be reviewed and approved by several members of the project. 

Informal

This work product is reviewed, but not formally approved. The work product is developed and maintained. It is normally not discarded after the project is complete and there isn't any review record. For example, individual design classes and low-level source code may not be formally reviewed. This can still mean that someone, perhaps a peer, will review it. 

None

This work product does not need to be reviewed or approved. The work product is created as work information. It is often a temporary work product that is discarded after the project is complete. 

Common Pitfalls

Identify issues, don't fix problems

One of the major reasons why review meetings fail to achieve their intended results is that they have a tendency to degenerate into discussions of how a problem should be fixed. Fixing problems usually requires investigation and reflection; the format of the review is not an effective medium for this kind of discussion. Once the issue is identified, determine if it is a defect that must be resolved, and then assign it to someone to investigate and resolve. The review meeting should focus on identification only.

If the issue requires further discussion among a group of people, form a separate meeting to focus on that topic. Typically this meeting will require some investigation and preparation, and people with the right skills will need to be involved. The review should remain focused on identifying other issues. The moderator will often need to exert considerable will to keep the review meeting focused on this.