Iterative Waterfall

2015-01-13

 

Although agile processes are becoming commonplace in many organisations, many developers and projects are still stuck in some form of waterfall and classical project management, especially in large organisations. (Like me.) But within the constraints of classical project management, some agile practices can be applied. In the case of this post, I will look at iterations.

Iterations are not something new that agile processes brought to the development scene. But they make it a core mechanic of the process. The core idea is to reduce the feedback loop. One thing that the water wall fails to do well.

Classic Waterfall

The classic waterfall model splits the project into 5 steps. Each step feeds into the next and they are processes in order. The primary problem with waterfall is that commonly projects may take years to complete. The first feed back received is then the project enters testing. This is two thirds to three quarters into the project and is may turn out not tow work out properly.

Full Waterfall in Cycles

The simplest adaptation of the waterfall process is to reduce the project length. Instead of implementing a new version of the software over the course of two years, you implement a version over the course of three months. Over the course of two years you will then have 8 versions, though not every version needs to go to the customer.

The primary advantage is that existing process can be used. This is especially useful if you need to follow a specific process for compliance with laws and regulations. It also gives stake holders the option to change their mind about what requirements they want to have implemented.

Iterations within Classic Process

A different approach is to maintain the requirements phase and the acceptance phase in the classical sense. But iterate the design, implement and test phases.

This approach is useful when the only people who believe in agile processes are the developers. The problem is that many organisations have existing processes that codify how requirements are "dumped" into research and development. The requirements and acceptance phase are the interfaces to the larger organisation, everything in between could be fairies and unicorns.