When Should You Use Agile vs Waterfall?

A delegate asked me this last month, and the way he asked it told me more than the question itself. He wanted to know which one he should be "moving towards." Not which one fit the project in front of him. Towards, as if one of them were the future and the other was something to be quietly retired.

That framing is everywhere. It treats agile and waterfall as two tribes, and treats picking one as a statement about how modern you are, rather than a decision about how a specific piece of work actually needs to run. I understand why. Agile has spent a decade being marketed as the enlightened choice, and waterfall has spent the same decade being cast as the thing enlightened teams grow out of. Neither framing survives contact with an actual delivery environment.

Here's what the question usually misses. A project doesn't ask to be agile or waterfall. It asks a much narrower set of questions, and the answers to those tell you which approach fits, almost without you needing to decide anything at all. How stable is the requirement. How expensive is a mistake, once it's built. Who needs to sign off before work can start, and how often. Whether the people who'll use the output can actually look at something unfinished and tell you if it's wrong.

Most teams skip straight past those questions and argue about methodology instead. I've watched a delivery board spend forty minutes debating whether they were "a Scrum team or a stage-gate team" for a piece of work that had a fixed regulatory submission date, a fully specified requirement, and almost no room for the requirement to change once submitted. The methodology argument was, in that instance, entirely beside the point. The constraint had already answered the question. Nobody had checked what the constraint actually was before opening the debate.

The reverse happens just as often, and it's usually more damaging because it's less visible until late. A software team is told the project will run to a waterfall structure because that's what the client's governance office expects to see reported against. Full specification up front, phase gates, sign-off at each stage. The trouble is that nobody in the room, including the client, actually knows yet what the finished product needs to do. The requirement is going to move, because the only way to find out what's right is to build something and let people react to it. Forcing that kind of work through a plan-once, build-once structure doesn't make it more disciplined. It just delays the discovery of the mistakes until the point where they're most expensive to fix, and dresses that delay up as rigour.

So the honest answer to "agile or waterfall" is neither, asked that way. Waterfall earns its keep when the requirement is genuinely stable, when a mistake discovered late is costly or dangerous to unwind, and when there's a real external gate, regulatory, contractual, or safety-critical, that has to be satisfied before work proceeds. Infrastructure, construction, anything with a formal assurance process, tends to sit here for good reason, not out of habit. Agile earns its keep when the requirement can't be fully known until people see something and react to it, when the cost of learning that early is lower than the cost of committing to the wrong thing at scale, and when the people who need to give feedback are actually available to give it as the work progresses. Product development, anything genuinely exploratory, tends to sit here.

Most real delivery work doesn't sit cleanly at either end. A construction programme with a fixed planning consent date might still run its internal design coordination iteratively, testing options with stakeholders before the drawings are frozen. A software product with a hard, fixed compliance deadline might still need a phase-gated structure around the parts that genuinely can't move, while running the build itself in short cycles. Treating the whole thing as one binary choice usually means forcing a structure onto parts of the work it was never suited to, just to keep the reporting simple.

None of this is an argument for calling everything hybrid and declining to make a decision. It's an argument for asking the actual questions, stability of the requirement, cost of a late mistake, the presence of a hard external gate, availability of real feedback, before reaching for a label. The label should describe what you decided to do. It shouldn't be what you decided in place of actually looking at the work.

If you're weighing this on a live project rather than in the abstract, it's usually worth talking it through with someone who's had to make the call both ways, and get in touch about your delivery approach if that would help.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.