The term “Waterfall” highlights a problem, not a method, for software delivery
When the “Waterfall” diagram was first drawn, it was one engineer’s attempt to point out why the current way of delivering software was flawed.
In his 1970 paper MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS, Dr. Winston Royce only drew the “Waterfall” to explain the problem and then give some ideas on how to fix it.
His basic premise being, with a gated approach, once you move downstream it’s hard to return upstream. And the more you try to do before each gate, the harder this gets.
Royce goes on to redraw the diagram to show a number of feedback loops which he felt were necessary to incorporate. As new information is uncovered during each stage, this is fed back into the relevant phase.
In the same paper, Royce advocates for doing it twice, i.e. going through the entire process first to create a simulation or prototype. This first-cut is then used to inform and de-risk around key areas of the product’s design as much as possible.
One other key recommendation Dr. Royce gives is that we involve our customer, as he puts it
To give the contractor free rein between requirement definition and operation is inviting trouble.
“Waterfall” isn’t a method
So, “Waterfall” is not a software delivery method, it’s the description of a potentially flawed, heavyweight approach.
Regardless of the method we use to deliver software, we go through a number of phases: requirements gathering/understanding, analysis, design, build, test and deliver.
The universal problem we have is there is often a degree of uncertainty that even the most rigorous process can’t uncover until we move to the next phase. This is coupled with fact that most times our customer doesn’t know exactly what they want until they see it and use it.
And this is a key aspect for software development teams to remember; we’re often building a tool for another human to use. For the customer to find that tool useful, then we have to understand the job they’re trying to do as clearly as possible. The most effective way to do that it through direct conversation and collaboration.
The key difference between the different methods is how we choose to involve the customer. The Agile movement chose to adopt a deliberately lighter, more interactive approach.