Understand Agile by Understanding How It’s Not Waterfall


Many engineers and managers have a really hard time with the Agile project management methodology (the “new way” of building things). They desperately want to have Agile projects, but implementing the methodology is a struggle. One way that I have found to be useful in understanding and implementing Agile is by doing a compare and contrast with the Waterfall methodology (the “old way” of building things).

However, most people do not understand the Waterfall methodology; the very thing that Agile is attempting to fix in order to make developing software more effective and manageable. If you do not understand what the ineffective way is, how can you successfully avoid it?

The Waterfall Straw Man

A common symptom of misunderstanding Waterfall is the ritual building and burning of the Waterfall Straw Man. If you work in software long enough, you will hear all about the Waterfall Straw Man. You’ll hear a collection of arguments about how some action/process/etc. is bad because it is “too waterfall”!

  • We can’t predict the end date; that’s waterfall.
  • We can’t plan out all the features or tasks; that’s waterfall.
  • We can’t have meetings; that’s waterfall.
  • We can’t make document; that’s waterfall.

Waterfall becomes the culmination of every ridiculous or bad practice we’ve experienced or heard about in a software project. It’s the boogeyman of managing software projects. On some teams even the accusation of “waterfall” is enough to kill any process.

The Facts about Waterfall

What is Waterfall really? The funny thing is that Waterfall is actually a very successful project management method throughout the world in manufacturing and construction. The following is the simplified waterfall approach:

  1. Identify a Project
  2. Plan the project
  3. Implement the Plan
  4. Deliver Tangible Output to the Customer

That’s it! That is waterfall! It actually has several benefits. One is that comprehensive planning up front allows effective resource planning. Also, discovering and fixing problems early on is less costly than dealing with them later. You might argue,

“Well obviously the problem is that Waterfall is not Customer centric.”

Wrong. Including the customer in the planning of a waterfall project is not uncommon. You might instead say something like the following,

“Well obviously the problem is that Waterfall doesn’t have Sprints/Standup Meetings/Backlogs/etc. !”

And you would be wrong. Waterfall can have any of those things. Those processes and components are popular in but not specific to Agile.

The Waterfall method successfully builds furniture, cars, bridges, and skyscrapers every day throughout the world. Sometimes, a customer is unhappy with the result but Waterfall gets it right many times.

The Case for Agile

So then, why use Agile if Waterfall is so great? Waterfall is very poor at managing change; which we have learned is exceptionally common in software development (nobody really knows why). A central tenet of Waterfall is that plans are made upfront, complete, and comprehensive. Changing a plan later is rare and exceptionally costly because a waterfall plan is so large scale.

You can read the Agile Manifesto to see what the creators intend Agile to be. Knowing their intent, I suggest these three, concrete improvements that Agile makes to Waterfall:

  1. Iterative Processes
  2. Frequent Delivery of Tangible Output

The Agile method would be applied in this manner:

    1. Identify a project.
    2. Plan what you know as best you can; Include the customer in the planning.
    3. Execute the project plan to deliver some tangible output to the customer quickly for validation.
    4. Discover new information from (a) your development and (b) the customer upon your delivery.

… Iterate over steps 2-4 until the desired output is delivered.

Wait! All that planning sounds an awful lot like Waterfall. Of course it does! Making plans was never the problem with Waterfall. Inability to change plans based on new information is the problem with Waterfall.

Scrum, Kanban, Xtreme Programming, and other Agile methodologies have a lot of additional behaviors and processes, but they are all built on this frame: (1) Iterative process and (2) frequent delivery of tangible output.


Do not fall into the trap of burning the Waterfall Straw Man. It benefits no one. In fact, I have seen some software teams implement Agile so poorly that they run into more problems than if they just implemented a straightforward Waterfall plan. At least then they would have planned before coding, interacted with the customer at least once, and worked to deliver what they promised in their plan. Better than nothing!

Agile is absolutely the way to go when building Software. It also works in other projects where change management is important (which is a surprising number of projects). Take the time to understand Project Management so that you can benefit from these proven practices.

Understand Agile by Understanding How It’s Not Waterfall