Agile vs. Waterfall: How to Choose an Approach for Your Project

"Should we use agile or waterfall?" is one of the first questions a new project raises, and it is often argued as if one side must be wrong. In practice, the two are different answers to a more useful question: how much do you know at the start, and what does it cost to discover you were wrong?

This guide explains each approach in plain terms, shows the trade-off that really separates them, and gives you a short set of questions for choosing, including the common middle path of mixing the two.

What "waterfall" means

Waterfall is a sequential approach. Work flows through phases, typically requirements, design, development and testing, and each phase finishes before the next begins.

The U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506, reissued December 15, 2023) traces the model to a 1970 paper by Dr. Winston W. Royce, "Managing the Development of Large Software Systems." GAO points out two details that surprise many people: the paper "never uses the term 'Waterfall,'" and it actually noted that the sequential model is risky because "it is unknown how the system will actually work until the testing phase," recommending iterative interaction between steps. The sequential version became the standard anyway.

GAO summarizes the approach this way: waterfall "starts by developing a plan for all requirements and ends when those requirements have been completed." Project management guidance often calls this a predictive life cycle, because it relies on predicting the full scope early.

What agile means by contrast

Agile approaches, by GAO's description, start "by developing a high-level program goal and priority requirements" and end "when the program goal has been met," with everyone understanding that requirements will be refined as small pieces are built and shown to customers for feedback.

Instead of doing all the requirements, then all the design, then all the building, an agile team does a little of each in every short cycle. GAO describes requirements, design, development and testing being performed "concurrently in small iterations for Agile and sequentially in Waterfall development."

The Agile Manifesto's principles explain the motivation: deliver working results early and often, welcome changing requirements "even late in development," and treat working software as "the primary measure of progress."

The real trade-off: what is fixed and what flexes

The single most useful idea for beginners is this comparison from GAO: "In a Waterfall development, the requirements are fixed but schedule and cost are variable, while in Agile development, the program cost and schedule are fixed but the requirements are variable for each iteration."

In everyday terms:

• With waterfall, you agree on the whole list of what will be built. If it turns out to be harder than expected, the date or the budget moves.
• With agile, the team works in fixed time periods at a known cost. What moves is which features get done, and the most valuable ones are done first.

That is why agile can deliver something useful early. GAO is careful not to overpromise, though: "there is no guarantee that Agile development will deliver the full capability more quickly than Waterfall development." What agile is intended to do is deliver working pieces sooner, because waterfall "does not deliver functional capabilities until the program is complete."

When agile tends to fit

GAO describes agile as "well suited for programs in which the final product is to include distinct features, some of which may be discovered during the process rather than planned at the beginning." The 2020 Scrum Guide makes a similar point, describing Scrum as a framework for "complex problems" and grounding it in empiricism, the idea that "knowledge comes from experience and making decisions based on what is observed."

GAO also lists indicators that a program is ready for agile, while noting this is not the only way to judge readiness. They include:

• Requirements are flexible, with a process to refine them over time.
• A champion or sponsor is available to help the team overcome obstacles.
• Users or subject matter experts are readily available to give feedback.
• Teams have been trained and a facilitator is available.
• Supporting functions, such as contracting, are willing to change to make agile work.
• Teams want more responsibility and ownership.

When a plan-first approach may fit better

GAO is direct about the limits: "Agile is not necessarily the solution for all programs." It notes that "not all programs will have flexible requirements, allowing trade-offs to occur between scope with schedule and costs."

For example, imagine a team that must produce a report whose contents and deadline are fully set by an outside rule, or a move to a new office where steps must happen in a fixed order. When the scope is known, stable and has to be delivered all at once, a sequential plan is often a sensible choice. Even then, many teams borrow agile habits such as short check-ins and regular retrospectives.

Hybrid is normal, not a compromise

You do not have to pick a pure version of either. The Agile Practice Guide, Second Edition, created in partnership between Agile Alliance and the Project Management Institute (PMI), is described on Agile Alliance's site as helping readers "choose fit-for-purpose approaches across predictive, Agile, and hybrid life cycles," including "continuum and hybrid models" and tailoring guidance.

Agile programs are not plan-free either. GAO notes that high-level planning happens at the start of an agile program and that programs "still define their overall goal in a vision and typically plan the releases needed to satisfy the vision."

For example, imagine a community nonprofit organizing a fundraising event and launching a new donation website. The venue contract, permits and date are fixed and sequential, so those get a conventional plan. The website, where nobody yet knows what donors will respond to, gets built in two-week slices with feedback from a few volunteer testers. One project, two approaches, each used where it fits.

Five questions to help you choose

Answer these honestly with your team and sponsor:

1. How well do we understand what is needed? If the answer is "very well, and it will not change," lean predictive. If it is "we will learn as we go," lean agile.
2. Can the people who will use the result give feedback during the work? Agile depends on it.
3. Is a partial result useful? If a first slice can help someone, incremental delivery pays off. If nothing has value until everything is finished, the benefit shrinks.
4. What is truly fixed: the scope, the date or the budget? Agile works best when scope is the thing allowed to flex.
5. Will the organization support it? Sponsors, decision-makers and contracts need to allow changing priorities, or the team will be agile in name only.

If your answers are mixed, that is a strong hint that a hybrid approach is right. Whatever you choose, write down why, and revisit the decision once you have learned more.

For a refresher on the values behind all of this, see our beginner's guide to what agile actually means.

Key takeaways

• Waterfall runs phases in sequence; agile repeats short cycles of planning, building and testing.
• GAO's summary: waterfall fixes requirements and lets cost and schedule vary; agile fixes cost and schedule and lets requirements vary per iteration.
• Agile aims to deliver usable pieces sooner, but GAO notes it does not guarantee finishing everything faster.
• Agile fits best when requirements will be discovered along the way and users can give regular feedback.
• Hybrid approaches are common and recognized in the Agile Practice Guide from Agile Alliance and PMI.

Sources

• U.S. Government Accountability Office, GAO Agile Assessment Guide: Best Practices for Adoption and Implementation, GAO-24-105506 (November 28, 2023; reissued with revisions December 15, 2023)
• Agile Alliance, Agile Practice Guide – Second Edition (created with the Project Management Institute)
• Principles behind the Agile Manifesto
• Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide (November 2020)