Waterfall Is Never the Right Approach

March 15, 2014 — Posted by Al Shalloway

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:

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

Al Shalloway

CEO, Net Objectives, SPCT

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

I often hear that agile will not work when dealing with complex real-time embedded systems. What is everyone's take on that?

I would say especially in real time embedded systems the need for removing delays between the hardware folks and software folks is essential.  What may not work is Scrum.  But Scrum does not define Agile even though many confuse the two as being synonymous.  When is removing delays in workflow and feedback not a good idea?  When is getting to completion faster with smaller batches not a good thing?  The question is how does one define Agile.  All too many have been thinking about it as being iteration based only.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban