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?

Can Inspections Make Defect Prevention Effective?



“Yes”, says Capers Jones. Formal inspection of requirements, architecture, designs, source code, configuration files, build scripts and test cases enable project teams in finding critical defects.
The cost of defects (related to requirements or designs) found during later stages of lifecycle is enormous. The best way to deal with this issue is to detect defects at early stages. Inspection is a way to accomplish this.

Not all Agile teams do pair programming. What about designs? Or configuration files? Do we inspect? When inspection or reviews are not done, the result can be accumulation of technical debt. Right?

When we find defects through inspections and reviews, we get an opportunity to classify defects and identify the root causes. Remember 80/20 rule? When we do this we can reduce the number of defects in subsequent iterations.

Fagan inspection can be fine tuned to suit Agile projects. Instead of performing inspection in large groups, Agile teams can perform inspections or reviews in small groups of two to four team members depending on the criticality of such inspections or reviews. One or two hours per iteration spent on reviews and inspection in Agile projects can yield immense benefits.

Have we forgotten the value of inspections and reviews? Caper Jones’s article ‘Do You Inspect?’ is an eye opener for everyone. 

In the next blog "Inspections and Reviews in Agile Projects"  I have shared 5 pointers and additional questions.

Agile Myths and Misunderstandings

This post links to a free PDF eBook for you! In our industry we do come across myths and misinterpretations related to Agile Software Development and Agile Testing. Here are some examples.

1. Take the waterfall model and add one arrow
2. Agile means 'start coding with no documentation'
3. Agile means 'ad hoc' or 'no processes’
4. Agile means 'no planning'
5. Agile team members must be super stars
6. Agile is for product engineering only
7. Changes can happen on a daily basis
8. Agile is for development projects only
9. Agile impacts work-life balance
10. Agile is just another fad
11. TDD is enough to ensure software testing
12. A chain of unit tests is a complete regression suite
13. Agile doesn’t allow for long-term planning
14. Agile testing is all about unit testing, TDD, and test automation
15. In Agile projects process compliance is a big issue

Details on each of these are available in this freely downloadable PDF. Happy Reading!

Requirement Engineering: Ten Principles



1. Quality is the top priority and it is possible to deliver high-quality software. In order to make this happen, business analysts need to focus on delivering high-quality requirements. Obviously, both the form and the substance of specifications are equally important.

2. Understand the problem before specifying requirements. When business analysts understand the problem accurately, it is highly probable that they are going to create specifications that are very close to what the user wants.

3. Use appropriate tools, models and practices. It is necessary to understand the organizational culture of customers and be aware of what tools, models and practices have worked for them. Tools, models and practices that provided results in collocated teams may not work well in case of distributed teams.

4. Awareness, skills, techniques, and discipline are more important that tools. The outcome of any practice is not determined just by the tools that you use. For example, a plumber who is in-charge of your facility requires awareness of your facility. He needs to be skilled. He has to follow certain discipline and understand relevant techniques. Without these qualities, if he claims his strength because of a powerful tool set he has, he is a dangerous plumber. This applies to team members who participate in requirement engineering activities too.

5. Establish appropriate measurement criteria. How do you measure the progress of requirement engineering activities? It is necessary to have appropriate measurement criteria. Document exchange or data collection is not requirement engineering.

6. Establish an appropriate verification and validation criteria. How do you verify requirements? How do you validate them? It is essential to have appropriate criteria for V&V activities. Doing it right is more important that making it faster.

7. Good team and good management are vital to success. Technology comes next. Start-ups succeed when they have a good team that captures product requirements and a good management that fosters product development. Technology is essential. More than technology, a good team and good management are important.

8. Understanding of customer’s priorities is paramount. This is what helps the team understand priority requirements at early stages and find ways to deliver working software early. The more the customers see, the more they will need. Understanding customer’s priority is a way to deliver valuable features early. Delivering early is the way to understand what else the customer wants.

9. Use the most efficient communication tools. Information exchange over documents can lead to misinterpretation or inadequate grasp. White board sessions, walkthroughs, using face-to-face meetings or video conferencing sessions are the effective ways of information exchange.

10. Ask questions. While this is applicable for all areas of software engineering areas, it is very appropriate for requirement engineering. Questions based on various aspects such as business need, functionality, scalability, performance, usability, test data, data volume, geography of users, compliance, etc. help business analyst understand requirements in detail. Asking context-free questions are equally important to make a positive impact.