Waterfall Is Never the Right Approach

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

 

Originally written March 15, 2014

I often hear that there are cases where waterfall is best.  I don’t agree.

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 of requirements, analysis, design, code, test
  • we can hand work off with little to 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 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.

What Can We Do?

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:

  • 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.

One other note. We should remember waterfall is to Agile as mass-manufacturing is to 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.


This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.