Agile vs Waterfall: What the Debate Gets Wrong

The agile versus waterfall debate has been running for over two decades, and it has produced more cargo-cult behaviour than genuine insight. Teams adopt agile rituals without understanding their purpose. Other teams defend waterfall as rigorous when it is really just risk-aversion dressed up as process. The truth is more useful and less satisfying: both methodologies are tools, and neither is right by default.

What Waterfall Actually Is

Waterfall is a sequential development model. You define requirements completely, design the solution, build it, test it, and ship it — in that order, with each phase completing before the next begins. It was formalised in the 1970s for large-scale engineering projects where the cost of changing direction mid-build was genuinely catastrophic.

The model made sense for physical infrastructure. If you are building a bridge, you cannot decide halfway through construction that the span should be longer. The requirements must be fixed before concrete is poured. Software and digital products borrowed the model without inheriting the constraint that justified it — and that is where the trouble started.

Waterfall's core problem in a product context is that it assumes requirements are knowable in advance. In practice, they are not. Users behave differently than expected. Market conditions shift. A feature that seemed essential at planning turns out to be irrelevant when it ships six months later. Waterfall provides no mechanism for incorporating this reality. By the time you discover the product is wrong, you have already built it.

What Agile Actually Is

Agile is not a methodology — it is a set of values, articulated in the 2001 Agile Manifesto, that prioritise individuals over processes, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The methodologies that grew out of it — Scrum, Kanban, XP — are implementations of those values, not the values themselves.

The central insight of agile is that software development is a discovery process, not a manufacturing process. You learn what the right product is by building approximations of it, putting them in front of users, and iterating. This requires short cycles, fast feedback, and a tolerance for incompleteness that waterfall explicitly discourages.

Done well, agile creates a product organisation that is genuinely responsive. When a competitor ships a feature, or a user segment behaves unexpectedly, or a technical assumption turns out to be wrong, an agile team can absorb that information and change direction. A waterfall team is locked into a plan that was written before any of that information existed.

Where Agile Goes Wrong

Agile implementations fail in predictable ways. The most common is confusing the rituals with the values. A team can hold daily standups, run two-week sprints, and maintain a product backlog while operating in a fundamentally waterfall manner — requirements are fixed at the start of each sprint, there is no genuine feedback loop, and the backlog is really just a list of features decided by someone senior six months ago.

The second failure mode is using agile as cover for lack of planning. Agile does not mean you do not know where you are going. It means you hold your plans loosely and update them as you learn. A product team with no strategy, no roadmap, and no clear sense of what problem it is solving is not being agile — it is being directionless.

The third failure is treating every stakeholder request as a backlog item. Agile teams are often overloaded with input from sales, support, marketing, and leadership, all of which goes into a backlog that grows faster than it can be cleared. The backlog becomes a graveyard of good intentions rather than a prioritised plan of action.

Where Waterfall Still Makes Sense

There are contexts where waterfall remains the right choice. Compliance-heavy environments — certain financial products, medical devices, regulated infrastructure — require complete documentation and sequential approval processes that are incompatible with agile iteration. If your product needs regulatory sign-off before it can change, agile's short cycles create more problems than they solve.

Similarly, projects with genuinely fixed requirements and a known solution benefit from waterfall's predictability. If you are migrating a database from one system to another, the requirements are known, the solution is known, and the goal is execution rather than discovery. Agile adds overhead without adding value.

The key question is: how much do you expect to learn during the build? If the answer is very little, waterfall is efficient. If the answer is a lot, agile is necessary.

What I Have Seen in Practice

Across nearly a decade building financial protocols, I have worked in both modes and in everything in between. The most productive periods have shared a common characteristic: a clear product vision held loosely, with short delivery cycles and genuine mechanisms for incorporating what we learned into the next cycle.

The least productive periods — regardless of which methodology was nominally in use — were the ones where the plan was treated as fixed and feedback was treated as noise. It does not matter what you call your process if the underlying culture does not support learning and change.

The methodology debate is, in the end, a proxy for a more important question: does your organisation genuinely update its beliefs based on evidence? If yes, agile will work. If no, no methodology will save you.

A Practical Starting Point

If you are setting up a product process from scratch, start with short cycles — two weeks is a good default — and invest heavily in the feedback mechanisms: user research, analytics, and a direct line from customer support to the product team. Get something in front of real users as early as possible. The goal is not to follow a methodology; it is to shorten the distance between a decision and its consequences.

The best product teams I have seen do not identify strongly with either camp. They are pragmatic about process and opinionated about outcomes. That combination — flexibility on method, clarity on goal — is what actually produces good products.