Concepts: Benefits of Iterative Approach

Topics

An iterative approach is generally superior to a linear or waterfall approach for many different reasons.

It let you accommodate changes along the way.
It allows you to mitigate risks earlier.
It allows the organization to learn and improve.
It offer more opportunities for reuse, both internal reuse and external reuse.
It results in higher quality software, which has been more thoroughly tested.

Accommodating changes

It lets you take into account changing requirements. Requirements will normally change along the way.

Requirements changes have always been a primary source of project trouble, leading to late delivery, over schedule, with unsatisfied customers, and frustrated developers. Fred Brooks wrote 25 years ago: "Plan to throw one away, you will anyhow." Users will change their mind along the way. This is part of the human nature. Forcing the users to accept the system as they originally imagine it is wrong. They change their mind because the context is changing, they learn more about the environment, the technology, and they see intermediate demonstration of the product as it is being development.

It provides management with a way to do tactical changes to the product, for example, to compete with existing product.

You can decide, for example, to release a reduced-functionality product earlier to counter a move by a competitor, or you can adopt another vendor for a given technology.

It allows technological changes on the way.

If some technology changes, or becomes a standard, or new technology appears, the project can take advantage of it. This is particularly the case for platform changes, or lower-level infrastructure changes.l

Mitigating risks

It lets you mitigate risks earlier, because many risks are only addressed, or discovered, during integration.

As you unroll the early iteration you go through all core workflows, exercising many aspects of the project: tools, off-the-shelf software, people skills, and so on. Perceived risks will prove not to be risks, and new unsuspected risks will show up.

Integration is not one "big bang" at the end—elements are integrated progressively.

Actually the iterative approach is almost continuous integration. What used to be a long, uncertain, and difficult time taking up to 40% of the total effort at the end of a project, hard to plan accurately, is broken down into six to nine smaller integrations that start with far fewer elements to integrate.

Increasing reuse

It facilitates reuse, because it is easier to identify common parts as they are partially designed or implemented, compared to having to identify all commonality up front.

Identifying and developing reusable parts is very hard. Design reviews in early iterations allow architects to identify unsuspected, potential reuse, and subsequent iterations allow you to develop the and mature this common code.

It is easier to take advantage of commercial-off-the-shelf (COTS) products.

You have several iterations to select them, integrate them, and validate that they fit in the architecture.

Learning

The developers can learn along the way, and the various competencies and specialties are more fully employed during the whole life cycle.

Testers start testing early, technical writing starts early, and so on, rather than waiting for a long time just making plans and honing their skills. The need for additional training or external help can be detected in the early iteration assessment reviews.

The process itself can be improved, and refined as it develops.

The assessment at the end of an iteration not only looks at the status of the project from a product-schedule perspective, but also analyzes what should be changed in the organization and the process to perform better in the next iteration.

Higher quality

It results in a more robust architecture because errors are corrected over several iterations.

Early flaws are detected as the product matures during the early iterations. Performance bottlenecks are discovered and can be reduced, as opposed to being discovered on the eve of delivery.

It results in a more thoroughly tested product.

The critical functions have had many opportunities to be tested, over several iterations. The tests themselves, and any test software will have had time to mature, as opposed to test run once towards the end of the project.