Inspections and Reviews in Agile Projects



In my previous blog "Can Inspections Make Defect Prevention Effective?" , I emphasized on spending one or two hours per iteration on reviews and inspection in Agile projects. Also, I wrote that Fagan inspection can be fine tuned to suit Agile projects so that team members can perform inspections or reviews in small groups of two to four team members,  depending on the criticality of such inspections or reviews. In this blog, let us go through when and how this can be done in Agile projects.

1. Review of requirements. Group reviews makes sense in agile projects. In one of the distributed agile projects we had scheduled conference calls to walk-through requirements at the beginning of iteration. These conference calls were more beneficial than 1-1 interactions because, the entire team could understand and ask questions as group. As a group, we found gaps in requirements and related one user story to another and refined user stories. Don’t we call this backlog grooming?

2. Review of architecture and designs. This is not about ‘big-upfront’ architecture or design. I have come across situations in agile projects that required our team to do complex designs in order to move forward with reasonable modularity in code. These designs are either UI designs or UML notation etc. In this context, it is valuable to involve all team members and perform group review. This step helps us improve the quality of design.

3. Code Refactoring.  Whether you do pair programming or not, it is a good practice to convene meetings at regular intervals (typically once in a month or on need basis) to discuss some of the key code refactoring instances. This can be a part of ‘retrospectives’ too. More than this, for critical chunks of source code, group review with two to four engineers is the way to go.

4. Test Case Reviews. At regular intervals, group review of test cases can help agile teams improve the quality of requirements as well as test cases.

5. Configuration Files, Build Files, etc. When two or more engineers come together and review configuration files they can streamline the placement of configuration parameters in the right files. Also, reviews of build files can minimize build failures due to scripting or configuration errors.

Typically these reviews in traditional projects used to take 10 to 15% of efforts. Should we invest in inspections and reviews to eliminate defects proactively? Why not? Ultimately, when we find ways to implement continuous improvement through this experience, we get to improve process as well as product quality.

One may think or argue that practices such as pair programming and ‘retrospectives’ enable agile teams practice continuous improvement and that is sufficient.  'Retrospectives’ are iteration specific. Do we get to apply 80/20 rule by gathering cumulative data of all past iterations in Agile projects? If no, don’t we have to?