 | Level: Introductory Anthony Crain, Lead Process Specialist, RUP Deployments, IBM
15 Dec 2007 
from The Rational Edge: Reviews are a great way to improve quality on a waterfall project. But for an iterative project, we want short cycles to do that job for us. This provocative article rethinks the role of reviews in iterative development lifecycles.
From The Rational Edge.
When software development teams or individual practitioners move from a waterfall approach to an iterative one, they tend to do too many reviews when engaging in the iterative lifecycle.
This is understandable. In a waterfall-type process, reviews are vital to success, because, teams do not revisit code developed earlier; i.e., they do not go backwards to a previous "phase." Also, waterfall cycle times are long, so that by the time problems are discovered downstream, the authors are often unavailable to help -- and even when they are, they have forgotten much of what the work was about! Reviews are the only safeguard against poor quality when you're using a waterfall approach.
By contrast, iterative development uses short cycles (3-9 weeks on average). Each team member has a role dedicated to the success of the iteration, rather than to the completion of their own unique discipline. This means that when a problem is found downstream, the key players are not only available, they are ready and expecting to continue to contribute to work they had begun earlier in the lifecycle.
The nature of review
When developers review things, they have a tendency to pounce on any little mistake they see regardless of its importance to the success of the iteration. They set aside the wise old saying, "perfect is the enemy of good," because reviews seem to demand that we strive for perfection. In a short iteration, however, we are not being so "reflective," but rather more focused on getting the work done. When we have a question about an upstream artifact, these questions usually just slow things down.
So the philosophy in using an iterative approach is this: Let the iteration prove itself. Allow things of questionable quality to proceed. When the item is actually used, that is when we'll learn if it was good enough or not.
Here's another feature of reviews: When people are asked to review something, they often procrastinate, skip the review, or do the review quickly but poorly. The Fagan Inspection Process, created by Michael Fagan, improved this dramatically with the "Reader" role, which, when done correctly, requires the consumer of the work product to explain what they understand about each portion of the artifact. By doing this aloud, many issues are uncovered that would otherwise be missed.
The genius of this process was in recognizing that the main voice in the review needed to be the downstream consumer -- i.e., the person most motivated to ensure quality in an artifact since they are going to have to work from it. With iterative development, the same principle is true, except that rather than reviewing an artifact before handoff, the artifact is actually put into use immediately, with the author still available to improve it during actual use. This results in improvements that are the most important, without a lot of extra effort hours.
Rethinking review
So does this mean there shouldn't be any reviews in an iterative lifecycle? No, but they should be conducted much less frequently than most project teams do, especially if the team's roots are in a waterfall type of methodology. If you truly embrace the iterative approach, the number of reviews should automatically be reduced. For example, if the iteration is six weeks long, how many reviews can you really hold and still finish the iteration's work?
If you believe that reviews can increase the quality of key artifacts, fine; add this step to your process. Just bear in mind that in iterative development, it is usually essential to create a plan for demonstrating your iterations. In the Inception phase, the projects I manage show a mapping of each use case to each Construction iteration, then a second mapping of specific flows to each Elaboration iteration that will get coded and tested.
For review-minded project teams, there's an extra step as well in the Inception phase. They will need to map each artifact they want to review to the iterations. Given that they are limited to 0-3 artifacts per iteration at most, three reviews for a six-week iteration will prove burdensome. The prospect of all this overhead will reduce the number of reviews, thus providing plenty of notice for planning of the reviews and ensuring that the right people show up.
Before I became proficient in iterative development, I, too, fell into the frequent-review trap. I was Fagan-trained, among other techniques, and had seen great benefits from our inspection process. It took a lot of trust for me to accept that "the iteration will prove itself." It also requires wisdom to find the right balance, but once the teams I worked on took the leap, it was incredibly worthwhile.
Review workshops
In some cases, the goal of review is to gain agreement. One example is the project Vision, one of the key artifacts of the Inception phase, and a document that must be agreed upon before key roles can move to further work during Inception. The Vision document is the greatest risk mitigation factor during Inception, ensuring that our iterations will have a solid scope they are working within, or improving upon.
Rather than a "review," we use "workshops," such as the Vision Workshop where we collaboratively create the high-risk artifact with key stakeholders. This type of artifact can be reviewed, but the collaborative creation of the artifact ensures quality more than a review normally would. When the review does come, if it does, we share metrics -- such as "100 stakeholders have helped to shape this vision." At review time, only five of us are reviewing, and, clearly, the review is not nearly as powerful as the joint crafting was.
Conclusion
Reviews are a great way to improve quality on a waterfall project. But for an iterative project we want our short cycles to do that job for us. True, reviews can improve our process and improve the visibility into our solution. But short iterations will accomplish both of those things better as well. Having too many reviews is typical for teams moving from waterfall lifecycles; those teams especially need to focus on reducing reviews and trusting the iterations to drive success and quality instead.
Resources
About the author | 
| | Anthony Crain is a software engineering specialist with the IBM Rational Services Organization. In addition to helping clients roll out the IBM® Rational Unified Process®, or RUP®, he also trains engineers in requirements management with use cases, object-oriented analysis and design (OOAD), and RUP. He learned OOAD and use-case modeling while at Motorola for five years, then sharpened his skills at Rational. An honors graduate from Northern Arizona University, he holds a B.S. in computer science and engineering.
|
Rate this page
| |
