Category Archives: Agile versus Waterfall

What Does ‘Waterfall’ Really Mean? How Do People Use That Word?

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?

What Does ‘Waterfall’ Really Mean?

Strictly speaking, the word ‘Waterfall’ was originally defined in 1970 by Dr. Winston Royce in his very famous paper:

Dr. Winston Royce’s 1970 Waterfall 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:

It was called ‘Waterfall’ because the results of one phase flow into the next phase like a ‘Waterfall’.

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

Overall Summary

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:

Free Agile versus Waterfall course

Learn the Truth About “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. Learn the Truth About “Agile” versus “Waterfall” – True “Waterfall”, as a methodology, died a long time ago for most projects outside of some specialized areas like construction; yet people continue to make that comparison.

The problem is that the word “Waterfall” is used very loosely and indiscriminately. In many cases, when people use the word “Waterfall”, they’re not using it to refer to the specific “Waterfall” methodology that was originally defined by Winston Royce in the 1970’s, they’re using it loosely to refer to a general style of project management that emphasizes some level of planning, predictability, and control over agility. Here’s an example – iterative methodologies such as the Rational Unified Process (RUP) became very popular in the 1990’s and early 2000’s and many people would consider that to be “Waterfall” just because they are somewhat plan-driven, but they don’t really fit the full definition of “Waterfall” at all.

An Example of Sloppy Terminology

Don’t get me wrong – I think Agile has huge benefits. I just want people to objectively understand the benefits of Agile versus Waterfall and the sloppy use of terminology to compare the two is often misleading and confusing. Here is an example I’ve taken from a real world source that is considered fairly credible to illustrate what I mean by sloppy use of technology when people talk about “Waterfall”:

Blue Line

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?

How can anyone possibly say that “The agile process is the universal remedy for software development project failure”?)

Blue Line

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. When people use the word “Waterfall” like this, I’m tempted to ask, “Which aspect of ‘Waterfall’ are you referring to?”

  • Are you referring to the phase gate approach where a project is broken up into phases and there is a phase gate for approval to transition between phases? I don’t think that approach has been widely practiced for years for software development projects and even Winston Royce himself had reservations about it
  • Are you referring to an over-reliance on documentation? That is a more legitimate comparison because Winston Royce did come out very strongly in support of a lot of documentation, but that shouldn’t imply that an Agile project has no documentation whatsoever.
  • Are you referring to the tendency to plan an entire project upfront before starting the project and then manage changes to the project requirements through change control? That also might be a legitimate comparison, but it also shouldn’t be meant to imply that an Agile project shouldn’t do any planning upfront.
  • Are you referring to the practice of attempting to complete all of the project requirements all at once? Long before Agile became well-known, iterative approaches like the Rational Unified Process (RUP) provided a way to solve that problem and break up a project into iterations.

A More Meaningful Comparison

A more meaningful and more objective comparison is between an “adaptive” approach to project management and a “plan-driven” approach to project management. “Plan-driven project management” is a style of project management that is applied to projects where the requirements and plan for completing the project can be defined to some extent 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 and the requirements and plan for the project are expected to evolve as the project progresses.

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, and you won’t find many projects 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:

Increasing Agility and Adaptivity

It is a matter of choosing the right level of upfront planning to be applied to a project based on the level of uncertainty and other factors in the project and it takes some skill to do that.

There is nothing inherently wrong with either of these approaches (adaptive or plan-driven). They both have advantages and disadvantages for a given project and they should be seen more as complementary approaches rather than competitive. Instead, many people see “Agile” and “Waterfall” as binary and mutually-exclusive choices and that causes people to try to force-fit a project to one of those extremes rather than selecting and tailoring the approach to fit the project. For example,

  • If I were to set out to try to find a cure for cancer and I attempted to apply a highly plan-driven approach to that project, the results would probably be very dismal
  • Similarly, if I tried to use an agile approach for building a bridge across a river, the results would be equally dismal

Why does that happen? It takes much more skill to fit a methodology (or combination of methodologies) to a project – you have to know a broader range of methodologies and you have to understand the principles behind the methodologies at a deeper level to know how to tailor the methodology and blend different methodologies together to fit a given situation. Some people are primarily skilled in one particular methodology and tend to implement that methodology mechanically “by the book”. It’s like being a carpenter and the only tool in your tool bag is a hammer.

Overall Summary

The impact of misusing the word “Waterfall” is significant:

  • It causes people to “throw out the baby with the bath water”. By misusing the word “Waterfall” and categorizing all plan-driven approaches as “Waterfall”, people tend to dismiss any form of plan-driven approach and to regard any kind of upfront planning as inconsistent with an Agile project.
  • It has caused a lot of polarization between the traditional project management community and the agile community. The perception is that project managers are associated with the Waterfall approach and, as a result, project management skills are not needed because the Waterfall approach is an out-of-date approach for many projects.

The true Waterfall approach has been obsolete for many projects for a long time (the exception being some selected industries like construction where it is still very useful and relevant). So, I don’t think comparing Agile to Waterfall is very meaningful any more, but its very difficult to get people to stop thinking in those terms because it has been so prevalent for such a long time.

The difference between a highly adaptive project and a highly plan-driven project is how much of that planning is done upfront in the project rather than being deferred till later. It’s not a black-and-white decision to have a totally plan-driven approach or a totally adaptive approach and it requires some skill and judgment to determine what level of upfront planning makes sense in a given project. When people present this decision as “Agile versus Waterfall” it distorts what the real decision is and makes it look like a binary, all-or-nothing choice and that’s not the case.

Additional Resources

I’ve created a free online training course that provides more information on this topic:

Learn the Truth About Agile versus Waterfall