Agile or Waterfall: a decision, not a religion

The methodology argument is almost never about methodology. It is a proxy for an unexamined question about uncertainty. Answer that one honestly and the framework mostly picks itself.

The question underneath

Ask this instead: how much of what we are building do we actually know?

Two kinds of uncertainty matter, and they are independent of each other:

• Requirements uncertainty — do we know what the thing should do?
• Technical uncertainty — do we know how to build it?

Plot a project against both and the answer stops being ideological.

Low on both, and you have built this before for a client who knows exactly what they want. A phased, sequential plan is not backwards here, it is efficient. Iterating on a known quantity is ceremony without benefit.

High requirements uncertainty, and the client has an ambition rather than a specification. Sequential planning will produce a beautifully documented plan for the wrong product. Iterate, show working software early, and let feedback resolve the ambiguity.

High technical uncertainty, and the team does not yet know whether the approach works. Time-boxed spikes before commitment, whichever framework surrounds them.

High on both, and you should reduce one before committing to a schedule. Discovery is not a delay. It is the cheapest part of the project.

Where Waterfall is the correct answer

There are contexts where sequential delivery is not a legacy habit but the right call:

• Fixed-price, fixed-scope contracts. If the commercial arrangement is sequential, running Scrum inside it creates a mismatch between how you work and what you are contractually obliged to deliver.
• Regulated work. When approval gates, documentation and audit trails are mandated, the phase structure is imposed from outside. You can iterate within a phase. You cannot iterate away the gate.
• Physical dependencies. Hardware, construction, procurement with long lead times. You cannot re-prioritise a shipment that has already sailed.
• Integration into someone else's timeline. When your work has to land on a date set by a third party, that constraint outranks your preferred cadence.

Where hybrid is honest, and where it is an excuse

Hybrid is legitimate when the layers are deliberately separated: a phase-gated programme structure for governance and external commitments, with iterative delivery inside each phase. The team works in sprints, the organisation sees milestones, and both get what they need.

Hybrid is an excuse when it means "we do stand-ups, but the scope is fixed and the date was set before anyone estimated anything". That is Waterfall with extra meetings, and the team will know it.

The real cost of choosing wrong

Choosing Agile for genuinely fixed-scope work produces churn: re-planning ceremonies that cannot change anything, and a backlog that is really a task list.

Choosing Waterfall for genuinely uncertain work produces something more expensive — a plan that is confidently wrong, then defended for months because too much has been invested in it to reopen.

The second failure is worse, which is probably why Agile won the argument culturally. But winning an argument is not the same as being right in every case.

In practice

Pick the framework for the project in front of you, say out loud why you picked it, and write down what would make you change your mind. A methodology you can justify is a decision. A methodology you default to is a habit.