Guidelines: Iteration Plan
 Iteration Plan |
A time-sequence set of activities and task, assigned to resources, containing task dependencies, for the iteration; a fine-grained plan. |
Topics
Iteration
Patterns 
Inception Iterations
In Inception, the top risks are often either business risks or technical risks. The dominant business risk early on is typically ensuring project funding. Thus, a proof of concept prototype is often the result of the inception phase. The proof of concept prototype either demonstrates key functionality or some essential technology.
The first iteration of a new product is usually the hardest. There are many new aspects a first iteration must achieve besides producing software: For example, putting in place the process, team-building, understanding a new domain, becoming familiar with new tools, and so on. Be conservative in your expectations about how much of the architecture you can flesh out, or the degree of usable functionality you can achieve. If you aim too high, you risk delaying the completion of the first iteration, reducing the total number of iterations, and hence decreasing the benefit of an iterative approach. The first iterations should be focused on getting the architecture right. You must therefore involve the architects in the planning process of early iterations.
Elaboration
Iterations
In Elaboration, the iterations focus on defining a stable architecture, on designing and implementing the essential behavior of the system and exploring the technical architectural issues through a series of architectural prototypes. "Architecturally significant" scenarios are sub-flows which exercise the architecture of the system in defining ways.
Construction and Transition Iterations
Toward the end of Elaboration, and during Construction and Transition, change requests (also known as Software Change Orders or SCO's) begin to drive the iteration process. SCO's result from:
- enhancement requests
- change requests whose scope goes beyond the individual package or class.
- changes in the iteration scope and objectives.
- changes in requirements either proposing that the requirements baseline be changed, or accommodating an accepted change to the requirements baseline.
These SCO's are balanced against the existing project plan, iteration plans, and the existing risk list. SCO's may cause the priority of requirements to be re-evaluated, or may drive the re-prioritization of risk. SCO's must be managed carefully, however, lest project control be lost.
During Construction and Transition, the focus is on fleshing-out the architecture and implementing all remaining requirements.
Iteration
Strategies
Unlike the Waterfall model, where the entire system is considered at once, we only consider a portion of the functionality of the system in each iteration. During each iteration, a subset of the total system is analyzed, designed and implemented. The choice of what the subset should be and how deep to delve are critical to reducing risk in subsequent iterations. There are two basic strategies: Wide/Shallow and Narrow/Deep.
Wide and Shallow
In the Wide/Shallow strategy, the entire problem domain is analyzed, but only the surface details are considered. All Use Cases are defined and most are fleshed-out in great detail, to get a clear understanding of the problem at hand. The architecture is defined broadly as well, and the key mechanisms and services offered by architectural components are defined; the interfaces of subsystems are defined, but their internal details are detailed only where significant risk or uncertainty must be managed. Very little is implemented until Construction, where most of the iteration occurs.
The Wide/Shallow strategy is appropriate when:
- The Team is inexperienced, either in the problem domain or in a technology area (including methodology or process).
- Sound architecture is a key requirement for future capability, and the architecture is unprecedented.
The strategy has some potential pitfalls, however:
- The team can get trapped in analysis paralysis (the illogical feeling that unless the design is perfect, one cannot implement anything).
- Early results are often needed to build confidence and credibility; the longer the project team goes without producing something executable, the less confident they feel about their ability to do so.
- Not enough of the technical details and challenges of the architecture are exposed to get a sense of the real technical risks
Narrow and Deep
In the Narrow/Deep strategy, a slice of the problem domain is analyzed thoroughly. The Use Cases related to this narrow slice are defined and fleshed-out in great detail, to get a clear understanding of the problem at hand. The architecture required to support the desired behavior is defined, and the system is designed and implemented. Subsequent iterations focus on analyzing, designing and implementing additional vertical slices.
The Narrow/Deep strategy is appropriate when:
- Early results need to be demonstrated to overcome a dominant risk, garner support or prove viability.
- Requirements are continually evolving, making it difficult to completely define all requirements before starting detailed design and implementation work.
- The deadline is mandatory, such that getting an early start on development is key to successful delivery.
- A high degree of re-use is possible, enabling a greater degree of incremental delivery.
The strategy is not without drawbacks:
- There is a tendency with this strategy for each iteration to develop software that is vertically integrated but horizontally incompatible. This is sometimes referred to as the stovepipe syndrome, and it makes a system difficult to integrate.
- It is not well-suited to developing systems in a completely new problem domain or based on an unprecedented architecture, since a large part of the functionality of a system must be sampled in order to achieve a balanced architecture.
Lessons Learned from Experience
Generally, early iterations will have more of a Wide/Shallow flavor, while later iterations (where a stable architecture has been developed) tend to follow the Narrow/Deep strategy.
The first iteration is usually the hardest, since it requires the entire development environment and much if the project team to be in place. Tool integration and team-building issues add to the complexity of the first iteration. Focusing on the architectural issues can help to maintain focus and prevents the team from getting bogged down in details too early.
Hybrid Strategies
Often, a Narrow/Deep strategy is needed in Inception, where a proof-of-concept is often needed to garner support. In Elaboration, the Wide/Shallow approach can help develop a sound architecture, with selective Narrow/Deep focus to address specific technical risks. In Construction, with a sound architecture established, the focus can return to Narrow/Deep, where functionality is developed and delivered in a series of integrated increments.
Special Considerations for New Teams
New teams are typically overly optimistic at first with what they can accomplish. To counter this, and to avert potential morale problems which occur when actual results fall short of optimistic expectations, be modest in the amount of functionality that can be achieved in the first iteration. Try to build experience while creating a sense of accomplishment and project momentum.
If the development environment and/or methods are new to the team, reduce the functionality of the first iteration to a minimum. Focus on integrating and tuning the environment and becoming proficient with the tools, then ramp-up the functionality content in subsequent iterations.
Expected
Rework
Rework is good, up to a point. One of the major benefits of an iterative development is precisely to allow mistakes and experimentation, but early enough so that corrective actions can be taken. However technical people in particular tend to 'gold plate' or redo work to perfection between one iteration and the next.
At the end of each iteration, during the iteration assessment, the team should decide what part of the current release will be reworked. Expect rework to be allocated among phases in the following percentages, relative to the total system:
- Inception, 40%-100% - this is where you may develop throwaway, exploratory prototypes
- Elaboration, 25%-60% in early iterations; less than 25% in later iterations, or for an evolution cycle.
- Construction, after the architecture baseline, 10% or less per iteration and 25% total.
- Transition, less than 5%.
Rework is inevitable. When no one sees the need for rework, you should be suspicious. This may be due to:
- Excessive pressure schedule.
- Lack of real test or assessment.
- Lack of motivation or focus.
- Negative perception of rework as being bad, waste of resources, or an admission of incompetence or failure.
Too much rework is alarming. This may be due to 'gold plating' or to an unacceptable level of requirement changes. A business case must be done to evaluate the necessity of some rework.
