Common Mistakes Implementing Iterative Development in the Construction Phase

In my consulting experience with projects implementing iterative development, I have witnessed five mistakes that seem common to practitioners implementing iterative development.

Mistake 1: Plunging into Construction Before the Project Is Ready

This mistake is common for those accustomed to Waterfall-style methods. Those who focus primarily on requirements elicitation and analysis seem particularly predisposed to this. You cannot move into the Construction phase simply because you have collected most or all the requirements. Although perhaps 80% of the requirements have been collected when Construction begins, this is a correlation, not a cause.

The key is to focus on the system architecture and other major risks that have been identified before the Construction phase begins. The primary requirements receiving the most attention during the Elaboration phase are those that exercise and prove the system architecture. Without proof of a stable, viable architecture, a move into the Construction phase diverts attention from risk mitigation. This can have disastrous effects later, because the failure to mitigate these risks early results in serious problems toward the end of the Construction phase, when an inadequate architecture becomes evident. By that time, much of the funding and resources on the project have been expended. You might be lucky and find that the architecture happens to be suitable, but why leave this to chance?

Mistake 2: Iterations of an Inappropriate Length

One project I worked on had six developers. When I looked at their schedule, they had iterations that were several months long. This dilutes some of the benefits of iterative development. For a small group of six developers, iteration lengths of 3 to 6 weeks are more appropriate. The idea is to exercise the complete lifecycle multiple times at frequent intervals. As development groups become very large (20 to 30 developers or more), iterations of 2 to 3 months may make sense. Larger groups are more difficult to control than small ones. Remember that iterations should be long enough to get something useful done, but short enough to create a sense of urgency in the development group.

Mistake 3: Iterations with No Stated Purpose

A project manager had determined the total length of time available to develop the system. He then chopped up the amount of time into equal-length periods and divided the requirements to be developed evenly across the periods. Then, he proudly proclaimed he was implementing iterative development.

Not by a long shot! Each iteration should have a specific purpose (usually determined by the risks remaining), and the requirements should be allocated to an iteration according to the criteria discussed earlier in this chapter. The success and lessons learned from an iteration are then used as input to help determine which items receive attention in the next iteration. Thus, you have the opportunity to make "course corrections" between iterations.

Mistake 4: Getting Derailed by Change Requests

Projects can become a victim of their own success. Sometimes, particularly after a demonstration, the customer and users flood the project with numerous change and enhancement requests. The development team, in an effort to be responsive to the customer, begins devoting more time to working on the change requests than developing the requirements. Actually, this may or may not be a mistake. The key is to stop and evaluate the reasons for the change requests. Are they mostly cosmetic requests? Are the users simply trying one last time to sneak in features that were rejected during requirements elicitation? If this is the case, the best course of action is to collect all these change requests and track them in some formal tracking system. Then, you can give your customer choices. Given limited time and resources, you can continue along the original path and deliver the IOC on time, but without all the change requests implemented. Or you can delay the IOC delivery and incorporate more of the change requests. Most customers will understand that last-minute change requests delay the implementation of new functionality. As a compromise, you can implement just a few of the change requests with each successive iteration.

If the team receives numerous change requests because the users are not seeing the functionality they expected, you have a more serious problem to solve. You might need to re-evaluate the requirements and review whether the project is headed in the right direction.

Mistake 5: Trying to Plan All Iterations in Detail Up Front

The whole point of iterative development is to use the lessons learned from one iteration to plan the next one. Based on the experiences of one iteration, you may learn or discover new information that causes you to alter what you had planned for the subsequent iteration. Because of this, it is usually a waste of time to plan every detail of every iteration up front. In all likelihood, the iteration will change anyway. A fine-grained, detailed plan is best used with the next iteration.