Benefits of an Iterative Approach

Compared with the traditional waterfall process, the iterative process has the following advantages:

• Risks are mitigated earlier.

• Change is more manageable.

• There is a higher level of reuse.

• The project team can learn along the way.

• The product has better overall quality.

Risk Mitigation

An iterative process lets you mitigate risks earlier than a sequential process where the final integration is generally the only time that risks are discovered or addressed. As you roll out the early iterations, you go through all process components , exercising many aspects of the project, including tools, off-the-shelf software, and people skills. Perceived risks will prove not to be risks, and new, unsuspected risks will be discovered .

If a project must fail for some reason, let it fail as soon as possible, before a lot of time, effort, and money are expended. Do not bury your head in the sand too long; instead, confront the risks. Among other risks, such as building the wrong product, there are two categories of risk that an iterative development process helps to mitigate early:

• Integration risks

• Architectural risks

An iterative process results in a more robust architecture because you correct errors over several iterations. Flaws are detected in early iterations as the product moves beyond inception. Performance bottlenecks are discovered when they can still be addressed instead of on the eve of delivery.

Integration is not one "big bang" at the end of the lifecycle; instead, elements are integrated progressively. Actually, the iterative approach that we recommend involves almost continuous integration. What used to be a lengthy time of uncertainty and pain ”taking as much as 40% of the effort at the end of a project ”is now broken into six to nine smaller integrations that begin with far fewer elements to integrate.

Accommodating Changes

You can envisage several categories of change.

Changes in Requirements

An iterative process lets you take into account changing requirements. The truth is that requirements normally change. Changing requirements and requirements "creep" have always been primary sources of project trouble, leading to late delivery, missed schedules, unsatisfied customers, and frustrated developers. But by exposing users (or representatives of the users) to an early version of the product, you can ensure a better fit of the product to the task.

Tactical Changes

An iterative process provides management with a way to make tactical changes to the product, for example, to compete with existing products. You can decide to release a product early with reduced functionality to counter a move by a competitor, or you can adopt another vendor for a given technology. You can also reorganize the contents of iteration to alleviate an integration problem that needs to be fixed by a supplier.

Technological Changes

To a lesser extent, an iterative approach lets you accommodate technological changes. You can use it during the elaboration phase, but you should avoid this kind of change during construction and transition because it is inherently risky.

Learning as You Go

An advantage of the iterative process is that developers can learn along the way, and the various competencies and specialties are employed during the entire lifecycle. For example, testers start testing early, technical writers write early, and so on, whereas in a noniterative development, the same people would be waiting to begin their work, making plan after plan. Training needs or the need for additional (perhaps external) help are spotted early during assessment reviews.

The process itself can also be improved and refined along the way. The assessment at the end of an iteration looks at the status of the project from a product/schedule perspective and analyzes what should be changed in the organization and in the process so that it can perform better in the next iteration.

Increased Opportunity for Reuse

An iterative process facilitates reuse of project elements because it is easy to identify common parts as they are partially designed or implemented instead of identifying all commonality in the beginning. Identifying and developing reusable parts is difficult. Design reviews in early iterations allow architects to identify unsuspected potential reuse and to develop and mature common code in subsequent iterations. It is during the iterations in the elaboration phase that common solutions for common problems are found, and patterns and architectural mechanisms that apply across the system are identified. For more about this issue, see Chapter 5, An Architecture-centric Process.

Better Overall Quality

The product that results from an iterative process will be of better overall quality than that of a conventional sequential process. The system has been tested several times, improving the quality of testing. The requirements have been refined and are related more closely to the users' real needs. At the time of delivery, the system has been running longer.