Methodologists speak of processes as heavy vs. light, and predictive vs. adaptive.
A heavy process has the following qualities:
- many artifacts created in a bureaucratic atmosphere
- rigidity and control
- elaborate, long-term, detailed planning
A predictive process is one that attempts to plan and predict the activities and resource (people) allocations in detail over a relatively long time span.
In contrast, an adaptive process is one that accepts change as an inevitable driver and encourages flexible adaptation; they usually have an iterative lifecycle. An agile process implies a light and adaptive process, nimble in response to changing needs.
We will see what means iterative development after the jump.
The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier deliverable versions of the system.
In this approach, development is organized into a series of short, fixed-length mini-projects called iterations; the outcome of each is a tested, integrated, and executable system.
Each iteration involves choosing a small subset of the planned requirements, and quickly designing, implementing, and testing them.
The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation to converge upon a suitable system. The system grows incrementally over time, iteration by iteration, and thus this approach is also known as incremental development.
Early iterative process ideas were known as spiral development (Boehm) and evolutionary development (Gilb).
The result of each iteration is an executable but incomplete system. Note that the output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production subset of the final system.
Although, in general, each iteration tackles new requirements and incrementally extends the system, an iteration may occasionally revisit existing software and improve it (refactoring); for example, one iteration may focus on improving the performance of a subsystem, rather than extending it with new features.
Iteration lenghts are recommended between two and six weeks: small steps, rapid feedback, and adaptation are central ideas in iterative development; long iterations subvert the core motivation for iterative development and increase project risk.
Much less than two weeks, and it is difficult to complete sufficient work to get meaningful throughput and feedback; much more than six or eight weeks, and the complexity becomes rather overwhelming, and feedback is delayed. A very long iteration misses the point of iterative development.
Short is good.
A key idea is that iterations are timeboxed, or fixed in length. For example, if the next iteration is chosen to be four weeks long, then the partial system should be integrated, tested, and stabilized by the scheduled date—date slippage is discouraged.
If it seems that it will be difficult to meet the deadline, the recommended response is to remove tasks or requirements from the iteration, and include them in a future iteration, rather than slip the completion date.
Rather than fighting the inevitable change that occurs in software development by trying (usually unsuccessfully) to fully and correctly specify, freeze, and “sign off” on a frozen requirement set and design before implementation, iterative development is based on an attitude of embracing change and adaptation as unavoidable and indeed essential drivers.
Early feedback is worth its weight in gold; rather than speculating on the correct requirements or design, the feedback from realistic building and testing something provides crucial practical insight and an opportunity to modify or adapt understanding of the requirements or design.
Customers have a chance to quickly see a partial system and confirm or correct it through the feedbacks.
Yet, this is not to say that iterative development encourages an uncontrolled and reactive “feature creep”-driven process —a middle way is possible.
In addition to requirements clarification, activities such as early testing will prove if the partial design and implementation are on the right path, or if in the next iteration, a change in the core architecture is required. Better to resolve and prove the risky and critical design decisions early rather than late—and iterative development provides the mechanism for this.
Consequently, work proceeds through a series of structured build-feedback adapt cycles. Not surprisingly, in early iterations the deviation from the “true path” of the system (in terms of its final requirements and design) will be larger than in later iterations. Over time, the system converges towards this path.
Some additional best practices and key concepts include:
- tackle high-risk and high-value issues in early iterations
- continuously engage users for evaluation, feedback, and requirements
- build a cohesive, core architecture in early iterations
- continuously verify quality; test early, often, and realistically
Conclusion: benefits of iterative development
- early rather than late mitigation of high risks (technical, requirements, objectives, usability, and so forth)
- early visible progress
- early feedback, user engagement – and adaptation – leading to a refined system that more closely meets the real needs of the stakeholders
- managed complexity; the team is not overwhelmed by “analysis paralysis” or very long and complex steps
- the learning within an iteration can be methodically used to improve the development process itself, iteration by iteration.