Project Management

Agile Vs Waterfall: Showdown For Software Development Domination

Published by in Project Management

The raucous crowd filling the arena is split into two bloodthirsty factions, one wearing shirts emblazoned with the letter A, the other bearing Ws. The fervor hits a crescendo as two familiar adversaries approach the ring from opposite entryways.

The first, an agile, young athlete with fists that flash like lightning and feet that dance like Ginger Rogers, wears an orange robe with a dragonfly on the back.

The second, an aging warrior with massive shoulders under a blue robe decorated with a crashing Waterfall, strides majestically toward the ring.

Two project management methods for software development enter the arena, but only one can be a champion.

Agile Vs Waterfall: The Tale of the Tape

The Agile Vs Waterfall debate has been going on ever since the Manifesto for Agile Development was conceived in 2001 by 17 software developers looking for a flexible improvement on the proven but rigid Waterfall style. The origins of incremental, iterative software development can be traced back to the 1950s.

The Agile Model



Waterfall, named so because of its sequential, or falling, approach, was born out of the process for manufacturing spacecraft. It was first formally described in the context of software development by Winston W. Royce in 1970 and has faced heavy criticism ever since from software developers due to its inflexibility and dependence on paperwork.

The Waterfall model

Professor Philippe Kruchten of the University of British Columbia summed it up when he said that software development “inherited the Waterfall cycle from other engineering disciplines, where it has proven very effective… Since then it has been a bit abused by organizations that used it blindly in circumstances for which it was not suitable.”

Yet, in 2015, 56 percent of IT projects still used the Waterfall approach, according to a Gartner research report, so it has plenty of dedicated supporters.

Agile wants its championship belt once and for all.

Let’s get ready to rumble!

1. Round One: Quality

Agile relies on iterative testing, gradually improving working deliverables throughout the process, to ensure quality. The developers and testers work side by side for better communication. Agile’s goal is to have quality assurance baked into every step of development, assuming open communication between developer and client.

Agile and Waterfall circle the ring, sizing each other up. Agile feigns a few punches then moves in to push the pace…

Waterfall has a proud history of quality. After all, it was good enough to land men on the moon and bring them home safely. However, because all testing takes place near the end of the process, fixing bugs can require a large-scale teardown and rebuild.

Round One score: Agile 1, Waterfall 0.

2. Round Two: Communication

Agile favors constant face-to-face communication and closely aligned teams over paperwork, while Waterfall relies heavily on documentation and Gantt charts. Because of this, Agile has less red tape and adjustments can be made quicker, as opposed to, for example, having to wait for the project leader to respond to an email before beginning work on a vital change.

Agile sends Waterfall reeling with a strong left hook to the rib cage!

Excessive and aimless communication can become a distraction from producing working deliverables. For heavily regulated government projects, Waterfall’s easily accessed requirements can be helpful. And if someone leaves a Waterfall team mid-project, the rigorous documentation allows a new contributor to pick up where the former team member left off.

Round Two score: Agile 2, Waterfall 0.

3. Round Three: Project Efficiency

Because of its open-ended nature, Agile’s roundtable approach to communication can also lead to risk inflation if the developer and customer cannot find a middle ground. This is where a good project manager must function to keep both sides on target.

Agile dances around the ring, tiring itself out by throwing shadow punches, while Waterfall pivots methodically and lands a flurry of jabs…


When cost and schedule are of the utmost importance, Waterfall flexes its muscles thanks to a strict adherence to budgets and deadlines. And because of the extra planning upfront, problems are more likely to be weeded out before the project even begins.

This makes Waterfall an excellent development method for highly structured projects where post-production alterations are unacceptable (such as in government IT projects).

Round Three score: Agile 2, Waterfall 1.

4. Round Four: Flexibility

Agile delivers working iterations to the customer in short cycles (plan, estimate, prioritize, execute, adapt), allowing ample opportunities for both parties to shape and adapt the product before it is finalized. However, a good project manager must push for realistic and concrete deadlines to prevent scope creep and endless cycles.

Agile sees an opening and strikes with a devastating uppercut!


Each step of the Waterfall process (requirements, design, implementation, verification, maintenance) is dependent on the completion of the step before it, so one kink anywhere in the pipeline can bring the entire process to a halt.

Developer and customer must agree on the nature of the final product before development begins, limiting opportunities for innovation mid-project. The benefit, though, is that stakeholders know exactly what they’re investing in once the project has started.

Round Four score: Agile 3, Waterfall 1.

5. Round Five: Customer Satisfaction

Agile allows the customer to take an active role in development from start to finish, like a pizzeria with a picture window into the kitchen. Because the customer gets working iterations throughout, they can speak up to mold and refine the final product to their specifications. However, if the customer decides that they want extra toppings, it’ll cost them. And they might later regret the decision to add asparagus AND hot dog slices, but hey, their call.

Agile begins to feel the crowd’s energy, showing off with fancy footwork while Waterfall breathes heavily.


Waterfall relies on a strict adherence to the upfront plan agreed upon between developer and customer. If the customer is not satisfied with the final product, either the developer did not follow the plan, or the customer failed to adequately communicate their requirements.

As an advantage, customers of Waterfall projects can generally expect to see their final product delivered on time and on budget.

Round Five score: Agile 4, Waterfall 1.


Agile, by unanimous decision!

  • Quality: Agile
  • Communication: Agile (knockdown)
  • Project Efficiency: Waterfall
  • Flexibility: Agile (knockdown)
  • Customer Satisfaction: Agile

According to a Gartner report (“The End of the Waterfall as We Know It” by Matthew Hotle and Nathan Wilson):

“Quite simply, Waterfall methods, when used in the traditional, project-based manner, are inconsistent and risky. Since there are other choices available that have the potential to be more consistent and less risky, it’s time to begin the transition to these methods.”

If you want to teach agile to your tech team, we have you covered!

Ironically, Royce—the founding father of Waterfall development—seems to have suggested against a rigid adherence to Waterfall software development in his original paper on the topic (which, curiously, never even mentions the term Waterfall).

In “Managing the Development of Large Software Systems,” Royce wrote “I believe in this concept, but the implementation described… is risky and invites failure.”

So maybe Royce knew all along that his contender would eventually be defeated. And maybe—like a mixed martial artist that borrows the best skills from a range of disciplines—the champion software development model of the future will be a hybrid of Agile, Waterfall, and whatever else works the best.

Methods such as Wagile, Rational Unified Process, Sashimi, and Water-Scrum-Fall have embraced this way of thinking.

What have your experiences with Agile and Waterfall been like? Have you used different software development methods, or some combination of several? Please let us know your thoughts in the comments, and follow me on Twitter @CapterraAC to continue the discussion!

Looking for Project Management software? Check out Capterra's list of the best Project Management software solutions.

About the Author

Andrew Conrad

Andrew Conrad

Senior Content Writer @ Capterra, sharing insights about retail. Published in PSFK, Modern Retail, and the Baltimore Sun. Austin transplant. I love spending time outside with my dog or floating on the Colorado River in my inflatable kayak.


No comments yet. Be the first!

Comment on this article:

Comment Guidelines:
All comments are moderated before publication and must meet our guidelines. Comments must be substantive, professional, and avoid self promotion. Moderators use discretion when approving comments.

For example, comments may not:
• Contain personal information like phone numbers or email addresses
• Be self-promotional or link to other websites
• Contain hateful or disparaging language
• Use fake names or spam content
Your privacy is important to us. Check out our Privacy Policy.