Agile vs. Waterfall: What's the difference?

Waterfall's rigidity vs. Agile's flexibility

Unlike the Agile approach, the Waterfall model is rigid. It treats each software development lifecycle phase as a distinct, isolated event. Development teams must complete each phase in its entirety before moving on to the next phase.

Once teams begin a new phase, they cannot revisit prior phases. Progress happens only in one direction, just like water flowing over a waterfall. That's where the methodology's name comes from.

Unfortunately, the software development process rarely aligns nicely with such a rigid methodology. In fact, the Agile movement was a result of the software development community rebelling against Waterfall's strict and inflexible ways.

Why does Agile reject Waterfall?

In the 1990s, developers were becoming increasingly disillusioned with the Waterfall approach, which led to the emergence of new software frameworks and methodologies, such as the following:

• Extreme programming (XP).
• The Scrum Framework.
• Feature-driven development.
• Lean and Kanban.
• Scaled Agile (SAFe).

In February 2001, at the Snowbird Conference, leaders from these emergent software development approaches came together to create and sign the Agile Manifesto. This is why Scrum, Kanban, XP and Lean are commonly known as Agile methodologies, even though they were already in use well before the manifesto was written.

The Agile Manifesto

The Agile Manifesto is short, less than 500 words in length. It simply contains a set of four values and 12 Agile principles. A few of the notable Manifesto entries that contrast Agile against Waterfall include the following:

• Teams should prioritize "responding to change over following a plan."
• Teams emphasize "working software over comprehensive documentation."
• Changes to requirements are welcomed, "even late in development."
• Agile teams should "deliver working software frequently."
• Agile's highest priority is the "early and continuous delivery of valuable software."

Agile is more of a philosophy about how software should be developed than a prescriptive methodology or framework like Scrum. It also stands in stark contrast to the way the Waterfall model works.

How Waterfall and Agile compare

One of the biggest differences between Agile and Waterfall is the emphasis Agile puts on customer interaction and regular reviews and feedback loops. While Waterfall asserts that customer feedback and stakeholder interactions need not occur until the end-product is delivered, Agile practitioners know that they must follow other rules, such as these:

• Requirements can become outdated before development even begins.
• New technologies can force changes to even the best designs.
• Estimates of effort are rarely accurate and are often extremely flawed.
• Continuous user feedback ensures features actually serve end-user needs.
• Revised stakeholder priorities can shift development timelines and efforts.

Waterfall does not deal with these situations well.

When to choose Waterfall over Agile?

The traditional Waterfall model dates back to the 1950s with roots in construction, engineering and manufacturing practices. It was repurposed for the world of software engineering in the 1970s.

It makes sense to use a Waterfall methodology to build a bridge. You don't set the foundation for a two-lane thoroughfare only to find out halfway through that an eight-lane suspension bridge would work better. Similarly, when you manufacture a car, you give the keys to the owner after it's fully built. You don't ask the purchaser for feedback as the car goes through the assembly line.

For software development, such rigidity isn't helpful.

For software projects, if the requirements can be clearly defined upfront with minimal probability for any changes between the time the software is requisitioned and when it is delivered, then the Waterfall method makes sense, but such situations are rarely the case.

When to choose Agile over Waterfall?

For software development projects that involve ongoing engagement between the development team and the project stakeholders, choose Agile over Waterfall.

Thirty years ago, applications were developed in isolated silos and stakeholders and developers never interacted face to face. In modern software development environments, developers and stakeholders are often co-located in the same building and can easily converse in a hallway or over a cubicle wall.

Choose Agile, not Waterfall, when developers and stakeholders can easily exchange feedback and be transparent about the development process.

Darcy DeClute is a technical trainer and Agile coach who helps organizations apply Scrum-based principles to adopt a modern DevOps stack. She is a certified Professional Scrum Master, Professional Scrum Developer and Professional Scrum Product Owner as well as author of Scrum Master Certification Guide.