I often hear that there are cases where waterfall is best. I don’t agree.
Let me first point out, however, that the choice is not between waterfall and Agile. There are other approaches. There are also multiple aspects to consider:
- do we know the steps we need to take to accomplish our task?
- are all the people and capabilities we need to accomplish the task readily at hand?
- what is the chance of making an error?
I don’t believe adopting waterfall as an approach is ever a good choice. Waterfall comes with the following mindset:
- we don’t need feedback between the steps involved. In knowledge work this is often between analysis, design, code, and validation
- we can hand work off with little or no cost
- big batches are ok since they enable us to be more efficient
- specialized skills working only on their specialty is good
- we can understand the work to be done before we do it
- written requirements can specify what we need
Let me go through each of these:
1) we don’t need feedback between the steps involved. In knowledge work, evidence shows we do so that we can correct our misunderstandings. In manufacturing, or set process type work, the feedback is useful to detect when an error has taken place. In both cases not getting feedback creates waste. We understand requirements better when we do analysis. We understand analysis while in design… Interestingly enough. Royce’s original paper said waterfall wouldn’t work. People liked the simplistic model he presented instead of the one with feedback cycles built-in.
2) we can hand work off with little to no cost. When we hand work off, we lose a lot of information. We either have to re-learn that information or, more likely; we go with misunderstandings.
3) big batches are ok since they enable us to be more efficient. This has been proven inaccurate in many industries and is the heart of Lean. Eli Goldratt said it best – “Often reducing batch size is all it takes to bring a system back into control.” Waterfall does little to have us work on small batches – a vital thing to bring value to market quickly.
4) specialized skills working only on their specialty is good. Synergy is good. Cross-functional teams, when possible, are good.
5) we can understand the work before we do it. I hear a common refrain that “our customers know what they want after we show them what they don’t want.” This is because requirements elicitation is a discovery process.
6) written requirements can specify what we need. I’ll leave this to people’s experiences, and one of my favorite Churchill quotes – “This report, by its very length, defends itself against the risk of being read.”
In other words, the waterfall mindset is just not accurate. I would suggest where waterfall worked, people went beyond this mindset and did something else. For those who say, “Well, no one does pure waterfall, ” I suggest looking at what they did outside the waterfall that worked.
What Can We Do?
In knowledge work, we first need to realize that we should not be trying to do Agile. We should be trying to be as agile as possible – increasing our agility as an organization. This means:
- focusing on delivering business value quickly by selecting the most important things of value (this typically means smaller chunks to be delivered)
- having proper team structures to get the job done
- removing delays in workflow by having avoiding working on too many things (work on the most important ones without exceeding your capacity)
- shortening feedback cycles – always a good thing to get clarity on where you are and to detect errors quickly
There are more, of course. But I’ve picked these because these are things we can always do to some extent.
In manufacturing or processes where we understand what is to be done, Lean-thinking helps by detecting errors quickly and continuously learning how to do things better.
One other note. We should remember that waterfall is to Agile as mass manufacturing is lean manufacturing. In manufacturing, we know all of the steps to do but working in small batches with feedback is still better than big batches with testing at the end.