Agile vs Waterfall: How to Choose for Your Project

Waterfall has a poor reputation, and its supposed inventor would have agreed. Winston Royce’s 1970 paper “Managing the Development of Large Software Systems” laid out the strictly sequential flow from requirements to design, coding and testing. Right after that he wrote that this implementation was risky and invited failure. His recommendation: go through the process at least twice, starting with an early prototype.

People mostly remembered the first diagram. For half a century.

That’s why the agile vs waterfall debate is often fought with caricatures. What actually matters is narrower: which approach suits your project?

What really separates the two

The core difference isn’t tooling, daily stand-ups or a Kanban board. It’s when decisions get made.

Sequential projects make most decisions early. Specify, then design, then build, then test. Later changes are possible but expensive, because they ripple back through every phase.

Agile projects make decisions late and often. The 2020 Scrum Guide sets sprints at one month or less, each ending in a usable increment, and describes a Scrum Team of typically ten or fewer people. After every sprint the product owner can change course.

“Apparently high” is deliberate. Waterfall plans show a firm date. Whether it holds depends on whether the requirements were right on day one. Agile planning inverts this: date and budget are fixed, and scope adjusts.

Where agile thinking came from

February 2001 saw 17 software developers meet at the Snowbird ski resort in Utah and write the Agile Manifesto. It contains four value pairs, such as “responding to change over following a plan”. The key word is “over”. The manifesto doesn’t reject plans. It weights them differently.

Plenty of teams turned that into “we don’t plan any more”. That misreading is expensive. Agile projects still need a product goal, a budget and a rough release plan, as described in how to plan a software project.

What the evidence actually shows

Not much. Conference talks love the Standish Group’s CHAOS Report, which credits agile projects with far higher success rates than waterfall ones. Treat those figures with care. The raw data isn’t public, the definition of success changed in 2015, and researchers such as Magne Jørgensen and Chris Verhoef have sharply criticised the methodology of earlier editions, partly because the sample may lean towards failed projects. There’s also a possible selection effect. If agile gets used more often on smaller projects, the comparison skews, since Standish’s own data shows small projects succeed far more often than large ones.

The logic is more solid than the statistics. The more uncertain your requirements, the more early feedback pays.

A decision matrix: seven criteria

Swap belief for a sober assessment. Rate your project on each line:

Five or more lines pointing right make a strong case for agile. Mostly left, and a sequential plan is probably more efficient. Mixed pictures are normal, and then hybrid is the honest answer.

Hybrid: the pattern that works most often

Many successful projects combine both. Here is a proven pattern:

1. Up-front phase covering goals, frame, budget, non-functional requirements and high-level architecture.
2. Delivery in sprints from a prioritised backlog.
3. Fixed milestones for approvals such as a pilot launch or data migration.
4. Formal acceptance at the end of each release, with a written record.

That’s not a lazy compromise. Some things don’t evolve well iteratively. Rebuilding a database design after three months costs far more than a few days of up-front thinking.

Public bodies offer a useful model. The UK Government Digital Service manual runs agile delivery through discovery, alpha, beta and live phases, with a decision to continue or stop at each gate. That’s agile delivery wrapped in a governance frame, which is exactly what most mid-sized projects need. Regulated fields such as medical device software add documentation duties on top, and they can still run iteratively if traceability is maintained.

Typical failures on both sides

Sequential projects often fail because the requirements document is treated as truth when it’s really a hypothesis. Users see the software only after months, and core workflows turn out to work differently. Then comes a wave of change requests, which a disciplined change request process can at least keep under control.

Agile projects fail differently. There’s no product owner with real authority, the backlog grows unchecked, and after a year the money is gone with no coherent product to show. Sprints become rituals; retrospectives become chores. Agile without discipline costs more than any waterfall. Few people say that out loud.

The shared failure: picking a method because it’s fashionable, or because the vendor always works that way. Make the choice deliberately, at the start, against the criteria above.

What this means for budget and contract

Agile and a fixed scope at a fixed price don’t mix well. Agile with a fixed budget and flexible scope works fine, provided must-haves are clearly separated using MoSCoW prioritization, so everyone knows what’s guaranteed. Contract models are compared in fixed price vs time and materials.

To see how one studio blends both in its own products and partner builds, read how OnlineBuilders works, from idea to operation.

Next step: have the two or three key stakeholders score the decision matrix separately. Where your answers differ, you’ve found the real project question, and it needs settling before kick-off.