Agile vs. Waterfall: What's the difference?

How does Waterfall work?

The Waterfall model treats each software development lifecycle phase as distinct, isolated events. Development teams must complete each phase in its entirety before they move onto the next phase.

Furthermore, once teams move onto a new phase, they are not allowed to revisit a previous one. Progress through the development phases flows in only one direction, from the top to the bottom -- just like flow of a waterfall, which is where the model's name comes from.

Why does Agile reject Waterfall?

By the 1990s, developers began to reject the rigid structure of the Waterfall method of software development. This led to the emergence of new software development models such as:

• Extreme programming (XP)
• Scrum and Kanban
• The dynamic system development method (DSDM)
• Feature-driven development
• Crystal
• Pragmatic programming

In February 2001, representatives of these emergent software development models drafted and signed an Agile Manifesto. This is why Scrum, Kanban, XP and DSDM are often referred to as Agile methodologies, despite the fact that they were all in use long before the manifesto was signed.

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."

How do Waterfall and Agile compare?

Agile practitioners know that in the world of software development, things never go according to plan. Therefore, the impetus to continuously delivery software into the hands of the client is arguably the primary difference between Waterfall and Agile.

Waterfall asserts that customer feedback and stakeholder interactions need not occur until the end-product is delivered. However, Agile practitioners believe the following:

• Requirements can become outdated before development even begins.
• New technologies can force changes to even the best designs.
• Wireframes and visual renderings don't always translate well into webpages and mobile apps.
• Revised stakeholder priorities can shift development timelines and efforts.

Waterfall does not deal with these situations well.

When is Waterfall better than Agile?

The Waterfall model has its roots in construction, engineering and manufacturing dating back to the 1950s. The traditional Waterfall model was repurposed for the world of software engineering in the 1970s.

It makes sense to use a Waterfall methodology to build a house. You don't want to pour the basement for a two-bedroom home, only to have the client decide they want a six-bedroom mansion.

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 are 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.

When should you choose Agile over Waterfall?

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

There was a time 30 years ago where 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 colocated 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.

What are advantages of Agile vs. Waterfall?

Most organizations choose to take an Agile approach for the following five reasons:

1. Agile encourages testing and validation earlier in the software development lifecycle.
2. Continuous delivery in Agile is consistent with the DevOps' continuous deployment model.
3. The Agile feedback loop more directly involves stakeholders in the development process.
4. Agile makes it easier to adapt to changed requirements midway through development.
5. Agile projects are easier to start because development doesn't depend on complete requirements and analysis cycles.

Can you combine Agile and Waterfall?

There are zealots on both sides of the Agile vs. Waterfall debate, but in practice, most software projects do a little bit of both. The combination of Agile and Waterfall is colloquially referred to as either Agilefall or Wagile.

Banks, insurance companies and governments tend to perform upfront requirements gathering and analysis. They thoroughly scope their projects, do budget analysis and get sign-off from various stakeholders. That's very Waterfall in nature.

Then, when development begins, they use an Agile framework like Scrum or Kanban and do iterative development. Changes to the plan are allowed as software is continuously delivered to the customer. This is the essence of agility.

The industry trend for the last 20 years has been to move away from Waterfall and embrace an Agile approach. That is certainly the development strategy I recommend.

But at the same time, I won't judge you too harshly if you incorporate a little Waterfall into your Agile mix. Most organizations do.