What does ‘Waterfall’ really mean? Have you ever thought about that? It is often used in comparison to ‘Agile’ but do people know what they really mean when they compare ‘Agile’ to ‘Waterfall’? I think the word ‘Waterfall’ is one of the most loosely-used words in the English language (the word ‘Agile’ is not far behind).
When people talk about ‘Agile’ and ‘Waterfall’, it sounds like they’re comparing two very specific and well-defined methodologies that are binary and mutually-exclusive opposites of each other. However, when you dig into what the words ‘Waterfall’ and ‘Agile’ really mean, you quickly discover that’s a very inaccurate and misleading comparison.
What Does ‘Waterfall’ Really Mean?
Strictly speaking, the word ‘Waterfall’ was originally defined in 1970 by Dr. Winston Royce in his very famous paper:
He described a model that consists of a sequence of phases where the outputs on one phase flow into the next phase which looks something like this:
What Was Life Like Prior to ‘Waterfall’?
In order to better understand ‘Waterfall’, it is useful to understand what life was like prior to Waterfall and what problems it tried to solve. What preceded ‘Waterfall’ was a lot of poorly-organized development efforts with little or no structure, discipline, and planning. Some of the major problems with the that approach were:
- As projects grew in terms of scope and complexity with potentially much larger numbers of developers, it became apparent that a more planned and structured approach was essential to coordinate the work of large development teams
- The other major problem was that there was very limited predictability over the costs and schedules of software projects, there were many and frequent very significant cost and schedule overruns, and business sponsors demanded some level of predictability
For those reasons, when the Waterfall approach was originally defined, it was a big improvement to go from practically no methodology at all to a very well-defined process that provided:
- A “road map” to coordinate the work of multiple developers as well as integrating the work with any other essential resources outside of the immediate development teams, and
- A mechanism to gain some level of control over the scope of software projects in order to get more predictability of project costs and schedules
Many younger people today don’t appreciate that history and just criticize Waterfall as being bad without understanding the problems it was intended to solve.
What Were Some of the Problems With the Original Waterfall Approach?
As with many things, there is a “pendulum” effect and when the Waterfall approach was initially implemented there was somewhat of an over-correction in many cases. The pendulum swung in many projects from almost no control and discipline to very rigid control and discipline. The common practice when the Waterfall process was originally defined in 1970 was a very document-intensive and over-controlled process where you couldn’t exit a phase until all the documentation required to show that the work required for that phase had been completed, reviewed, and approved.
That was a very onerous process and had a number of problems that even Dr. Royce recognized in 1970 when he first defined the process. Some of the most serious problems were:
- The ultimate user of the software didn’t normally even see the software until all of the development and testing was complete and by that point in time; it was very difficult, if not impossible, to go back and make any significant changes
- The emphasis on control of scope made the process very inflexible to any changes that might be needed to meet user needs and business goals in an uncertain environment
As a result, there have been many situations where the project may have met cost and schedule goals but failed to provide a sufficient level of business value. Another major problem was that a heavy emphasis on documentation and other overhead required for reviews and approvals made the whole process bureaucratic and not very cost efficient.
How Did ‘Waterfall’ Evolve to Solve These Problems?
Before Agile came into widespread use, many variations on the original Waterfall model and other more iterative models were developed and used to create a more adaptive approach to solve some of these problems. One example was the Rational Unified Process (RUP) whose origins can be traced back to 1996 and 1997. RUP emphasized an iterative development approach to solve some of the problems in the original Waterfall approach. RUP and variations of RUP such as the Enterprise Unified Process (EUP) became very popular in the late 1990’s and early 2000’s.
As a result, if you look at what people have been doing in actual practice over the last 15-20 years, there has been a proliferation of a broad range of many different models (some of which have a very limited resemblance to the original ‘Waterfall’ model as it was defined in 1970). Yet people still loosely characterize all of that as ‘Waterfall’ as if it was one specific, unique and well-defined methodology called ‘Waterfall’ and that is not really the case. The way the word ‘Waterfall’ is used in practice, it actually refers to a broad range of different methodologies.
What’s a More Accurate Way of Describing ‘Agile’ versus ‘Waterfall’?
The common denominator of all the methodologies that people loosely call ‘Waterfall’ is that they emphasize some level of upfront planning and control to try to achieve predictability over project scope, costs, and schedules. For that reason, I think the word “plan-driven” is a more accurate and objective description of what people really mean when they say ‘Waterfall’.
The word ‘Agile’ is also loosely used. We all know that ‘Agile’ is not a specific methodology although many people equate ‘Agile’ with Scrum:
- Scrum is not really a specific methodology, it is really a framework that is intended to be adaptable to a broad range of situations
- Agile is not really equivalent to Scrum. There are other Agile methodologies such as Kanban
It’s pretty easy to see that the word ‘Agile’ is also used very loosely to imply a specific and well-defined methodology when that is not the case. The common denominator of methodologies that people call ‘Agile’ is that they are flexible and adaptive and emphasize creativity and innovation in an uncertain environment rather than emphasizing planning and control to achieve predictability with lower levels of certainty. For that reason, I prefer to use the word “adaptive” instead of the word ‘Agile’ when making comparing it to ‘Waterfall’ (plan-driven).
Why Is Comparing “Plan-driven” and “Adaptive” More Accurate and Objective?
Here’s why I prefer to use a comparison of “adaptive” and “plan-driven” rather than ‘Agile’ versus ‘Waterfall’:
- It’s more accurate – the word “plan-driven” doesn’t imply a specific methodology – it is a characteristic of a broad range of methodologies which I think more accurately describes what people are talking about
- It’s more objective – the word ‘Waterfall’ has lots of very negative connotations associated with it that go back to the original ‘Waterfall’ model that was defined in 1970 and what people call ‘Waterfall’ today may have little resemblance to the original “Waterfall model that was defined in 1970. The word “plan-driven” doesn’t carry any of that negative baggage
When people in the Agile community compare ‘Agile’ and ‘Waterfall’, it’s usually in the context of Agile is good and Waterfall is bad and that’s really not accurate and objective. Saying “Agile is better than Waterfall” is like saying “A car is better than a boat” – both have advantages and disadvantages depending on the environment that you are in.
- A plan-driven approach works best in projects that have a low level of uncertainty and require some level of predictability
- An adaptive approach works best in projects that have a high level of uncertainty and require an emphasis on creativity and innovation to find an optimum solution rather than an emphasis on planning and control to achieve predictability
I don’t think I have any hope in getting people to stop using the comparison of ‘Agile’ and ‘Waterfall’ – it’s too widely used – I even use it myself sometimes because it is a convenient and simple way of describing something that is actually a lot more complex. I just hope people realize what a huge over-simplification it is and how inaccurate and misleading it can be when people make the comparison of ‘Agile’ and ‘Waterfall’.
I have developed a course called “Learn the Truth About Agile Versus Waterfall” that provides more detail on this to help people see these approaches in a fresh new perspective as complementary to each other rather than competitive. You can check out that free course here: