Agile Versus Waterfall
How many times have you heard people compare Agile versus Waterfall?
- It happens a lot,
- I do it myself, and
- I keep hearing presentations that talk about how Agile has displaced Waterfall
But, if you really think about it, I don’t think that’s a very meaningful comparison and it’s out-of-date. The result of this confusion is people tend too see these two alternatives as binary and mutually-exclusive choices and they try to force-fit a project to one of these extremes:
There are many myths, misconceptions, and stereotypes behind the typical “Agile” versus “Waterfall” comparison. I hope this article will help people see these two alternatives in a fresh new perspective as complementary to each other rather than competitive.
What’s Wrong With The Typical Agile versus Waterfall Comparison?
“Agile” and “Waterfall” Are Not Individual Discrete Methodologies
When people talk about “Agile versus Waterfall”, it sounds like there are two individual discrete methodologies that can be directly compared:
- One called “Agile” and
- One called “Waterfall”
The truth is that neither “Agile” or “Waterfall” is an individual discrete and well-defined methodology. It would be more accurate to recognize that each one is a style of methodology with more than one different methodology associated with each style. For example:
What is the “Agile” Methodology?
“Agile” is not a single methodology. Agile methodologies include Scrum, Kanban, and other less commonly-used methodologies. Scrum is so widely-used, that when many people say “Agile”, they really mean “Scrum”; however, it’s not really accurate to say that “Agile = Scrum”. In addition, many people consider Scrum to be a general framework and not a specific methodology. Here’s some more detail on that:
The common denominator of these Agile methodologies is that they are flexible and adaptive. That makes them well-suited to an uncertain environment where an empirical process control approach is needed. I think the word “adaptive” is a much better and more accurate term to use to describe these methodologies because it defines a style of methodology and doesn’t convey the idea of a specific methodology at all.
What is the “Waterfall” Methodology?
“Waterfall” is also not a single methodology. When people talk about “Waterfall”, they are not necessarily referring to the pure original phase-driven approach defined by Dr. Winston Royce in the 1970’s. “Waterfall” has evolved significantly since those days and there are many variations that might still be considered to be “Waterfall”. For example, the Rational Unified Process (RUP) and its many variants probably would be considered “Waterfall”.
Again, when people use the word “Waterfall”, they are not generally talking about a specific methodology; they’re talking about a style of methodology. You will find more detail on that in this article:
The common denominator of these methodologies is that they are “plan-driven”. They emphasize trying to achieve predictability over the costs and schedule of a project plan. They do that by nailing down the requirements in detail upfront and controlling any changes once the project is in progress
It’s Not a Binary and Mutually-exclusive Choice
Another serious flaw in the typical “Agile” versus “Waterfall” comparison is that it implies that there is a binary and mutually-exclusive choice between these two extremes and that is also not the case.
These two approaches are not mutually-exclusive. If you recognize that these are really styles of methodologies and not really individual methodologies, there are many ways to blend the two styles together:
- Its not a matter of blending a Scrum methodology with a true Waterfall methodology;
- It’s a matter of blending a plan-driven style of methodology with a more adaptive style of methodology in the right proportions to fit a given situation.
Agile versus Waterfall – An Example of Sloppy Terminology
A lot of this is just sloppy use of terminology; but, in many cases, there’s also an implication that Agile is good and Waterfall is bad. Here is an example to illustrate what I mean by sloppy use of terminology when people talk about “Waterfall”:
From the 2011 Chaos Report: “Agile Succeeds three times more often than Waterfall” The report goes so far as to say, “The agile process is the universal remedy for software development project failure.”
What do they mean by “Waterfall”? (Are they talking about a specific methodology – like the Waterfall that was defined by Winston Royce in the 1970’s or are they talking about a broader range of plan-driven methodologies?
- How did they define how “success” was measured and how do you compare success from one project to another? Are the metrics for success really the same across all projects to make that comparison?
- How can anyone possibly say that “The agile process is the universal remedy for software development project failure”?
This is an example of some of the opinionated polarization that has existed for a long time. Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”. They both have advantages and disadvantages depending on the environment that you’re in.
A More Accurate and Meaningful Comparison
A more meaningful and more objective comparison is between an “adaptive” style of project management and a “plan-driven” style of project management.
- “Plan-driven project management” is a style of project management where the requirements and a detailed plan for completing the project can be defined prior to implementing the project
- In contrast, an “adaptive” style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented. Then, the requirements and plan for the project are expected to evolve as the project progresses
Neither of these is an absolute, rigid extreme. In reality, no project is ever totally plan-driven or totally adaptive; you won’t find many projects:
- That start out with an absolutely rigid plan that is not expected to change at all, or
- That have no plan whatsoever of how the project will be done
There is a broad range of alternative approaches between those two extremes as shown in the diagram below:
Fit the Methodology to the Nature of the Problem
A good rule to follow is don’t force-fit any project to any methodology that doesn’t fit the nature of the project. A methodology does not provide a “cookbook” approach for solving any problem you might have:
- Rather than force-fitting a project to some particular methodology (whatever it might be) and taking a “cookbook” approach to applying that methodology mechanically.
- The right approach is to go in the other direction and fit the methodology to the nature of the problem you’re trying to solve. It takes more skill to do that but it definitely can be done.
The impact of all the myths, misconceptions, and stereotypes behind the typical Agile versus Waterfall comparison is significant:
Don’t Throw Out the Baby With the Bath Water
By categorizing all plan-driven approaches as “Waterfall”, people tend to dismiss any form of plan-driven approach and regard any kind of upfront planning as inconsistent with an Agile project. That’s not the case.
Get Past the Polarization
There has been a lot of polarization between the traditional project management community and the agile community. There is a perception that project managers and project management are associated with the Waterfall approach. As a result, some people believe that project management skills are not needed at all because the Waterfall approach is an out-of-date approach for many projects.
There is actually a lot of project management going on in an Agile approach although you may not recognize it as “project management” for several reasons:
- It’s not the traditional kind of “project management” that is so heavily stereotyped. It’s a different kind of project management with an emphasis on maximizing business results rather than controlling costs and schedules.
- You also won’t typically find someone called a “Project Manager” at the team level in an Agile project because the functions that would normally be performed by a project manager have been distributed among other functions on the Agile team.
We need to get past many of the myths, stereotypes, and misconceptions that exist in this area. We need to see these two approaches in a fresh new perspective as complementary rather than competitive to each other.
You can find related articles on the topic of “Choosing the Right Approach” here:
You will find much more detail on this in my Online Agile Project Management Training.