Reviews and Walkthroughs.
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.
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 a number of books, that have each 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. Perhaps 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 come to the conclusion (and likely appropriately) that these reviews are continuous. The close and continuous exploration of artifacts and work products all open to reviews by team members. Product demonstrations are reviews of iterations on the way to the product. Retrospectives are reviews of the way the work is being done also. 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. It is similar 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.