Selecting Waterfall, structured, Iterative or agile for your software project

First lets understand the difference.

Waterfall Project

Waterfall is the most misquoted of all methods. Waterfall is defined by the simple fact that each stage in the project must complete fully and be agreed/signed-off before the next stage can begin.
Sometimes it is very important that the previous stage was fully and correctly completed. An example would be when the second stage can only be built if the first stage is already in place and performing correctly. That is a rare situation since we can use techniques like scaffolding to spoof a layer only creating the APIs. Another good reason would be that an early layer is experimental and therefore if the previous layer did not succeed, it would be time to end the project.
This is more common for product management and consulting projects where part of the deliverable is substantial research.


Structured Project Management

structured project


Structured Project Management is what they are often thinking about when they say waterfall. In this case the project is broken into clear stages, however common sense prevails and second or their stages can begin while the first is still in motion as long as there is no dependency. This is similar to what PMI refers to as a “Crashed Schedule”
Each stage still needs to end by passing through a stage Gate, just there are fewer delays.

Iterative Project management

iterative project

Iterative Project management is similar to structured, except that instead of stages you build small increments of the end result. These increments begin with an MVP that is carefully designed to provide the maximum value for the smallest amount of work and not to be replaced later but expanded on.  Key elements of incremental delivery are that A. The overall vision of a finished solution is understood from the outset even if the team are not rigidly wed to it. B. usable increments are released early and a feedback loop then serves to inform and sometimes change the scope of subsequent releases.


Agile delivery (Not Project management in my view, but software development)

agile delivery

Agile follows the same path as Iterative Project management, but especially with modern versions, there is often no attempt to envision the end result, but an MVP is built and the agile team then decide on very small increments to add in “Sprints” lasting as little as two weeks. Sprints are often not released because they are too trivial and a release cycle runs in parallel.
Other key aspects of Agile are the attempt to improve communication by encouraging conversation in place of documents, a team of peers without management to encourage taking ownership and responsibility and pair programming and multi-skilled individuals to avoid waste.
Most flavours require a Product owner or equivalent who should hold authority and responsibility for the product.

In summary

Waterfall is a very rigid method that produces low defect rates, but can run a long way over schedule and budget very easily. It seems to have a little bit of a cult following that hangs on and of course it is necessary in some situations.

Structured is a common-sense approach that closely resembles how we operate from day to day in other business areas. It inherits the benefits of Waterfall without the extra delays.

Iterative seems to have lost it’s appal, mainly because of the similarity of Agile which shares a key recognition point, however it contains all the common sense and safety valves of structured approaches alongside of the flexibility of agile.

Agile has a cult following and is done badly 90% of the time by people who totally misunderstand it.
Stakeholders will be heard saying they want agile because they need rapid releases. In reality what they need is incremental.  People compare agile to waterfall, but few people really do waterfall anyhow so it is a pointless comparison.