Reviews of all kinds

If you have been in product development for any time, you may have been involved in design reviews, walk-throughs, specification reviews, product reviews, audits and other forms.

Recently I was a part of a customer presentation.  The presentation was developed to introduce the customer to a new product design that the customer might believe to be better than their present production product.  There were many reviews of this presentation that describes the design, specific improvements, and manufacturing of the new product.  The presentation was well structured, and not overly lengthy. These reviews were well attended by a range of competencies, from design, manufacturing, and project management.   No worries, right? Wrong, or so it seems.

We can review product iterations as well.

Review Limits

In spite of multiple reviews and walk-throughs, an error was found in the presentation at the moment of presenting.  Okay, the error was a minor typographical error, not one that would have any serious consequence. However, it was indeed a defect in the presentation, after having been reviewed at least 3 times by no less than 5 people in each of the reviews.  I can relate to a defect slipping through.  We have written several books, each of which has gone through many reviews. Reviewed by the authors, reviewed by subject matter experts, and reviewed by the publisher. Guess what, things still slip through.

• How can we assess the value of the event that never happens, when we do not know what that would have been? What happens if we do not conduct these reviews?
• What do you think of reviews or walk-throughs? Do you conduct reviews of your product artifacts?

Agile and Pair Programming

In my experience, we find things during these critiques of artifacts.  Especially if that artifact will be a foundation for another effort. Whether or not we need to perform these reviews depends upon what is at risk. If you have had any experience in agile or scrum, you might have noticed that these reviews are often continuous by doctrine.  The close and continuous exploration of artifacts and work products are all open to reviews by the team.  Product demonstrations are reviews of iterations on the way to the product.  Retrospectives are reviews of the way the work is being done.  In these instances, perhaps we do not need to schedule these types of reviews.  It is arguable that these formalized approaches are not so important when there is a continuous, albeit informal review of the work approaches, interim work products, and even the final product.  Similarly for code reviews.  Code reviews may not be so necessary when we employ pair programming. Though we only have two people, four eyes, hopefully at least two perspectives (at least).  Done well it is continuous for the code creation.