The most formal version of reviews and inspection are Fagan-style inspections. Inspections are very rigorous in removing defects from any type of deliverable. However, the cost and overhead of these inspections have led to the development of a wide range of less formal techniques. The goal of the less formal techniques is find a balance between the benefit and cost of inspections. The least formal and most common review technique is the desk check.
Author – The author is the person that created the deliverable being reviewed. He or she sends the deliverable (or link) to the person doing the review, answers questions (if asked) and reacts to feedback.
Reviewer – Reads the deliverable and provides feedback to the author.
Simple Desk Check Process:
- The author recruits one or more reviewers. It is common courtesy to always ask before you send a document to be reviewed. When you ask, I suggest making sure that you provide the reviewer with any relevant context. Context can include information like an overview of your assignment, relevant standards and when you need the review completed.
- Send the deliverable or link the reviewer.
- The reviewer reads and comments on the deliverable based on the agreed upon time box. I believe it is a good idea that the reviewer write down any comments and defects to share with the author. The only exception to this rule is if the author and reviewer are in close proximity (such as pair programming) AND the problem can be fixed on the spot. Don’t trust memories.
The desk check process is very simple and very compact. All of my writings are desk checked by one or two editors. 99% percent of the time the review and my consumption of the information generated is asynchronous. They edit the document and then at some point in the future I make corrections. If my editors did not write down the feedback and just left a voice message I would never be able to remember the things I need to fix (it would also have to be a long message). On the occasions that we are in the same location the process is far richer because we talk and make corrections interactively (this is the power of collaborative reviews).
There is almost always no pre-work for this type of review.
A second type of less formal review is the walkthrough:
Author– Same as in the desk check, except when they act as the reader and scribe (see below)
Reader – Reads or presents the deliverable being reviewed. Almost always the author.
Scribe – Record comments and defects identified during the walk through. Many times this role is filled by the author.
Reviewer – Attends the walkthrough and provides feedback to the author. In more formal versions of a walkthrough, the reviewer may be asked to pre-read or pre-review the deliverable before the walk through.
A simple walkthrough process:
- The Author recruits reviewers. As in the desk check type of review, make sure that you provide the reviewer with any relevant context. Context can include information like an overview of your assignment, relevant standards and when you need the review completed.
- Send a meeting request for the walkthrough meeting. When remote participants are involved you will need to leverage collaborative tools that allow the deliverable to be shared and so that participants can hear each other.
- Send the deliverable or link the reviewers so they can prepare for the walkthrough. (Optional)
- During the walkthrough the reader presents or reads the deliverable to reviewers. The reviewers consider the material being presented and provide feedback that is recorded. In order for walkthroughs to be effective they need to be time boxed. 45 to 60 minutes is usually the limit of attention spans.
- After the walkthrough the author will need to follow-up on the comments and defects generated during the walkthrough.
My brother owns a firm that builds custom houses. In his business the walkthrough is a critical quality and communication tool to ensure the customer and his build crews stay synchronized.
The desk check and the walkthrough are generally less effective than an inspection. However, they strike a good balance between degree of rigor and their ability to find and remove defects. Rigor is highly correlated to cost and overhead. Informal and formal reviews and inspections can also be combined. For example, I recently reviewed a process for an avionic firm that requires all designs and code to be desk checked before it is formally inspected. The firm’s goal is to remove 99.9+% of the defects prior to a production release on all life critical software. Just because a review technique is informal doesn’t mean that it is not valuable.