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