Agile in Name, Waterfall in Practice

An organization can decide to adopt a framework overnight. It cannot decide to change how it actually thinks about building software. The gap between the two gets paid, quietly and personally, by whoever is standing in the middle.

Why Transformations Stall

At some point a leadership team decides the organization is “going agile”: adopting a scaled framework, standing up trains, running planning events, renaming the roles. The decision is real, the intent is usually sincere, and the vocabulary changes almost immediately. What does not change, because it cannot be changed by decision, is the belief system underneath the engineering organization: that you gather complete requirements first, then design the long-term solution, then build it once, properly. That belief is waterfall. Dressed in agile language, it becomes one of the most common and least-discussed failure modes in enterprise transformation – agile in name, waterfall in practice – and the cost of the mismatch lands on the people caught between the words and the behavior.

The tells

An organization running waterfall behind an agile vocabulary is easy to recognize once you know the signs, because the behavior contradicts the language at every turn.

The teams want the requirements upfront. Not a prioritized backlog to pull from and refine, but the full, settled specification before they will start, because in their model, starting without the complete picture is irresponsible. They talk in sprints but plan in specifications.

They idle while they wait for that specification, and the budget burns the entire time. An expensive team sits substantially unproductive, waiting for someone to hand them a finished definition of the work, and this waiting is treated as normal rather than as the alarming waste it is.

They have no interest in prototypes. A prototype, to a team that wants the requirements upfront, is not a learning tool: it is noise, a distraction from the real work of building the durable system. The single fastest instrument for discovering what to build is unwelcome, because the team does not believe the answer is something you discover; they believe it is something you are handed.

They want to build the long-term solution in one pass. Not a thin slice that proves the idea and then grows, but the whole, correct, architected thing, because iterating feels like doing the job twice. And teams get assigned by calendar and budget rather than by readiness: a delivery team materializes because the funding started, not because there is validated, buildable work waiting for it.

Any one of these can be explained away. Together they are a signature, and the signature says: this organization has adopted the ceremonies of agile and kept the mindset of waterfall.

Why the decree doesn’t change the behavior

The reason this happens is not stupidity or bad faith. It is a category error about what a framework is.

A framework is scaffolding: roles, cadences, ceremonies, artifacts. Scaffolding can be installed by decision, quickly. You can announce the trains, schedule the planning events, and rename the project managers by the end of a quarter. What a framework cannot install is the belief that you learn your way to the right solution rather than specifying it in advance. That belief is culture, and culture does not move on a memo’s timeline. So a decision to “go agile” reliably produces the visible layer: the stand-ups, the boards, the increment planning, sitting directly on top of an engineering mindset that still wants the complete spec before it begins. The organization now has agile ceremonies and waterfall behavior, and it experiences the combination as confusing rather than as contradictory, because the vocabulary insists everything is fine.

There is a deeper version of this worth naming. A system tends to reflect the structure and beliefs of the organization that produces it. An organization that is siloed and specification-driven will produce siloed, specification-driven work no matter what it calls its method, because the method is downstream of how the organization actually thinks and is organized. Changing the label changes the least important thing. The behavior follows the culture, and the culture was not in the room when the framework was chosen.

The person in the middle pays the gap

Here is where the abstraction becomes a human cost, because the gap between declared-agile and actual-waterfall does not stay abstract. Someone has to absorb it, and that someone is almost always the person doing the product or analysis work at the seam.

That person is asked to run genuine discovery: to prototype, to learn iteratively, to bring the business along, for a delivery team that wants none of it and is waiting for a specification. When a team is assigned overnight, with no architectural runway and no discovery track running ahead of it, there is no validated backlog waiting, because the organization never built the mechanism to keep one ready. So the person in the middle manufactures the work just in time: improvising a backlog in real time, night after night, to keep an idle and expensive team fed, while simultaneously being told to work in an iterative way the team does not accept. They become, personally and unsustainably, the entire missing layer between the two operating models: the discovery track that was never stood up, the runway that was never built, the translation between a method the organization declared and a behavior it kept.

It is exhausting in a specific way, because the work is invisible and the failure is pre-assigned. Do it well and the mismatch is hidden, so no one sees the problem. Do it at human pace and the idle team’s burning budget becomes your fault. You are held accountable for bridging a gap you did not create and were not empowered to close.

Why the engineers aren’t the villains

It would be easy to read all this as engineers being obstinate, and that reading is both unfair and useless. Wanting the requirements upfront and wanting to build a durable, long-term solution is not incompetence, it is a rational response to how engineers are usually measured and to what they have usually experienced. They are held accountable for delivering a correct, maintainable system, and half-formed direction that changes under them wastes their time and damages their work. If iteration has historically meant “we didn’t know what we wanted, so you built the wrong thing twice,” then resisting it is sensible self-protection.

And the leaders who decided to “go agile” are usually sincere, too. The failure is not villainy at either end. It is the belief that declaring the framework was the transformation, that the announcement and the ceremonies would carry the behavior along with them. They don’t. The declaration is the easy part; it is also the part most likely to be mistaken for the whole.

What actually closes the gap

Closing the gap is not a matter of insisting harder on the ceremonies. It requires building the substrate that agile behavior actually depends on, and changing what the organization rewards.

It requires an architectural runway, so that incremental delivery is even possible, so a team can ship a thin, real slice without being asked to design the entire long-term system first. Without runway, the demand for full upfront requirements is not unreasonable; it is the only way to build at all, which is why runway comes first.

It requires a discovery track running ahead of delivery, so that when a team is ready there is validated, buildable work waiting, instead of a person manufacturing it overnight. Teams should be assigned to readiness, not to the start of a budget cycle.

It requires making iteration safe and valued for engineers, rather than a threat to their craft, which means protecting them from the thrash they are rightly afraid of, and demonstrating that a prototype is how you avoid building the wrong thing, not evidence that you don’t know what you’re doing.

And it requires leadership to understand, and model, that “going agile” is a change in how the organization learns and decides, not a relabeling of what it already does. If the reward system still prizes the complete upfront specification and the single big build, the ceremonies are theater and the behavior will stay waterfall no matter what the boards say.

The giveaway question

There is one question that cuts through all the vocabulary and tells you which kind of organization you are actually in: does it want to learn its way to the solution, or does it want the specification so it can build the solution once?

An organization that wants to learn its way there will value the prototype, tolerate the thin first slice, staff teams to validated work, and treat changing its mind as evidence the process is working. An organization that wants the spec so it can build once will demand requirements upfront, idle while it waits for them, reject the prototype, and experience every change as failure, and it is running waterfall, regardless of how many agile ceremonies fill its calendar.

Naming which one you are in is the first honest step. The label on the wall will not tell you; the behavior will. And until the behavior changes, the organization has not transformed, it has renamed itself, and quietly handed the difference to whoever took the new name seriously enough to actually work the way it promised.