Contractual Issues Revisited
Earlier in this chapter, it was stated that toward the end of the Elaboration phase, the overall scope and length of the Construction phase are determined, including the number and length of iterations. This implies that the contractor can set the date of the IOC according to the project's needs. In an outsourcing situation, this is often not the case. A delivery date for the IOC may have been set contractually long before the Construction phase was set to begin. This could mean that you do not have sufficient time for enough iterations to completely deliver all intended functionality in the IOC. Although this is not an ideal situation, it is manageable. You have three alternatives:
The point is that some flexibility from the client is required.
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.