Note: Since this blog was posted we have created a webinar called Why You Should Never Do Waterfall, Often Do Agile and Always Do Lean.
As a side note, this blog was inspired by a response to my discussion on the Scaled Agile Framework linked in group called Challenging the assumption that one must get teams to work first, before going to scale (which I recreated as the blog prior to this).
I often hear that there are cases where waterfall is best. I don't agree.
I actually don't believe adopting waterfall as an approach is ever a good choice. Waterfall comes with the following mindset:
1) we don't need feedback between the steps of requirements, analysis, design, code, test. Well, history has shown us that we do. We understand requirements better when we do analysis. We understand analysis while in design, ... Interestingly enough. Royce's original paper said waterfall won't work. People just liked the simplistic model he was presenting 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 just go with misunderstandings.
3) big batches are ok since they enable us to be more efficient. This has been proven to be 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 - an important 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 to be done before we do it. A common refrain I hear is that "our customers know what they want after we show them what they don't want." This is because requirements elicitation is really 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" then I suggest look at what they did outside of waterfall that worked.
We first need to realize that we should not be trying to do Agile. We should be trying to be as agile as possible - that is, increase our agility as an organization. This means:
There are more, of course. But I've picked these because these are things we can always do to some extent. And, with a little observation, we can see that these are things SAFeTM is attempting to help us do.
NOTE: If you'd like to respond to this, please do so on the SAFe linked in group thread: Challenging the assumption that one must get teams to work first, before going to scale (I will not respond to comments here).
CEO, Net Objectives, SPCT