Water Scrum Fall

If you looked at a hundred large organisations that describe themselves as agile, the great majority would share the same delivery shape. At the front, a period of requirements gathering, business case approval, solution design and architectural sign-off, measured in months and producing documents. In the middle, teams working in two-week sprints with standups, boards, refinement and demos. At the end, a code freeze, a phase of integration and regression testing, a change advisory board, and a release into production some considerable time after the last sprint finished.

This is water-scrum-fall, and the name has been in circulation for well over a decade. It is not a transitional state that organisations pass through on the way to something better. It is a stable equilibrium, and it is stable because each of its three layers is locally rational for the people who own it. Nobody designed it. It emerged, the way a desire path emerges, from a large number of sensible individual choices made under constraints that were never examined together.

The important thing to understand about water-scrum-fall is that the iterative middle is real. The teams are not pretending. They genuinely plan, build, test and review in short cycles, and within the sprint boundary they are often very good. The problem is that the middle layer is sealed at both ends. Work arrives fully specified and departs into a queue, which means the iteration cannot do the one thing iteration exists to do: change what gets built in response to what was learned by building it.

That is the whole diagnosis. Everything else follows.

How to recognise it

The tell is not in the ceremonies, which will look exactly like the ones in the book. It is in what surrounds them.

Scope arrives complete and dated. The team receives a backlog that was written before they were involved, tied to a business case with a fixed set of deliverables, and a date that was committed in a forum they did not attend. Refinement in this context means decomposing the specification, not questioning it. The product owner's real job is sequencing a predetermined list, which is a very different accountability from the one described in what-a-product-owner-is-accountable-for.

Done does not mean released. Ask what happens to an item that the team marks done in sprint eleven. If the honest answer is that it waits for a release train, a hardening phase, a UAT window or a quarterly deployment slot, then the sprint boundary is a reporting checkpoint, not a delivery boundary.

There is a phase after the sprints. Look at the plan for a block of time between the last sprint and the go-live date, labelled integration, stabilisation, hardening, regression, or simply UAT. Its existence is the clearest single indicator, because it is an admission that the work completed in the sprints was not actually finished.

Design decisions are made before the teams exist. Architecture is settled in a solution design document, approved at a gate, and handed over. Teams that discover a better approach in week six must raise a change request against a design owned by someone who has moved on to the next programme.

The demo audience cannot change anything. Stakeholders attend the sprint review, express approval, and the backlog does not move, because the backlog is the contract the funding was granted against.

Defects cluster at the end. The bug count is low through the build phase and rises sharply during the test phase. This is not because the team got worse. It is because integration and realistic testing were deferred, and the defects were always there, accumulating invisibly.

Any two of these is enough. In most cases you will find all six.

Layer	Cadence	Typically owned by	What accumulates here
Upfront requirements and design	Months, once	Business analysis, architecture, the programme	Unvalidated assumptions, fixed scope
Iterative build	Two weeks, repeated	The delivery teams	Completed work waiting to be released
Batched release and hardening	Weeks to months, once	Release management, operations, governance	Integration risk, defects, deployment risk

Read the right-hand column as a description of where the batches form. The middle layer is the only one that is not accumulating a large batch, which is why it is the only one that feels healthy, and why improvement effort keeps getting aimed at it.

Why it persists

None of the people maintaining this shape are being stupid or obstructive. Each layer is held in place by a genuine constraint, and the constraints reinforce one another.

Funding is granted against scope. Money is approved annually or quarterly for a project with defined deliverables and a business case with a benefits profile. To get the money, someone had to state what would be built. Having stated it, they are accountable for delivering it. Discovering in month four that half of it is not worth building is, in this system, a failure to deliver rather than a success in learning. The upfront requirements phase exists because the funding model demands it, and no amount of agile coaching inside the teams will change a treasury process. This is the root constraint and it is addressed in from-project-funding-to-product-funding.

Procurement needs a specification. Where suppliers are involved, a contract must describe what is being bought. Fixed scope is the easiest thing to write, the easiest to evaluate competitively, and the easiest to defend at audit. The specification then becomes binding on everyone, including internal teams who never signed anything.

The release path is genuinely expensive. This is the constraint most often dismissed by people advocating change, and it is real. If deploying to production takes a weekend, involves manual steps, requires a change advisory board that meets fortnightly, needs coordinated updates to three other systems, and carries a meaningful chance of an outage, then deploying frequently is not a cultural choice that is being blocked by timid managers. It is an expensive, risky operation, and batching is the correct response to a high fixed cost per transaction. The hardening phase exists because the deployment is dangerous, and the deployment is dangerous partly because it happens rarely — a loop that will not break itself.

Risk ownership is separated from delivery. Somebody in operations, security or risk is accountable if a release causes an incident, and that person has no authority over how the software was built. Their only available control is a gate at the end. A gate is a crude instrument and they know it, but it is the instrument they have been given. Removing their gate without giving them a better assurance mechanism is asking them to accept unmanaged risk on someone else's behalf, and they will quite properly refuse.

The middle layer was the easy part to change. Adopting Scrum inside a team requires no change to funding, procurement, deployment tooling or risk governance. It can be done by a delivery manager with a training budget. Everything outside the team requires changing something owned by someone senior in another function. So the transformation went as far as it could go without needing permission, and stopped exactly at the boundary where permission was required.

What it costs

The costs are large and mostly invisible in standard reporting, which is why the shape survives so comfortably.

Feedback arrives after it can be acted on. The purpose of building something is partly to learn whether it was the right thing. In this shape, the learning arrives at UAT or at go-live, months after the decisions were made and after the budget is spent. Organisations in this state are not running an empirical process, whatever the ceremony calendar says.

Delivered scope includes a large fraction of waste. Every organisation that starts measuring feature usage discovers that a substantial share of what it built is rarely or never used. In a shape where scope is fixed upfront, that share cannot be discovered in time and is built in full.

The end-phase estimate is always wrong in the same direction. Integration and hardening phases overrun routinely, because they contain all the risk that was deferred from earlier and none of the information needed to size it. Programme plans that are accurate until the last sprint and then slip by a third are the signature of this shape.

Defect cost multiplies with delay. A defect found by the developer who wrote it costs minutes. The same defect found in a regression phase three months later costs a bug report, a triage meeting, a person re-learning unfamiliar code, a retest and a release note. Deferring detection is not deferring cost; it is increasing it.

Every release is a high-stakes event. Large batches fail in correlated ways and are hard to diagnose, because when four hundred changes ship together and something breaks, there are four hundred suspects. This drives more process, which raises the cost of releasing, which increases batch size. The mechanism is set out in batch-size-and-the-cost-of-big-releases.

The teams stop believing. This is the cost that compounds worst. Engineers see that their two-week cadence has no bearing on when anything reaches a user, that the demo changes nothing, and that the retrospective actions concern matters inside a boundary that does not contain the actual problem. The ceremonies come to be experienced as compliance. Once a team has learned that, the credibility required for any future change is gone, and the next initiative will be received as the last one was.

Why attacking the middle does not work

The reflex response, when the results disappoint, is to improve the sprints. Better refinement, a stricter definition of done, more training, a maturity assessment, a coach per team. A great deal of money goes into this every year and it does not move the delivery outcome, for a reason that is straightforward once stated.

The middle layer is not the constraint. If the front end fixes the scope and the back end batches the release, then making the build phase twenty percent faster shortens a fourteen-month cycle by a few weeks and changes nothing about the quality of what was chosen or the risk of the release. You are optimising the only part of the system that was not the problem — the same error described in why-busy-teams-are-slow-teams, where touch time is small and queue time is everything.

Worse, improving the middle can make things actively worse. A faster build phase feeding an unchanged release process just means more completed work sitting in the queue, which increases batch size and raises the risk of the eventual release. Teams that become more productive in a water-scrum-fall shape frequently find that their cycle time gets worse, and are understandably confused.

Dismantling it from the ends inward

The middle is fine. Attack the ends, and attack the back end first, because it is the one you can move without a treasury conversation.

Start with the release path, because it is a technical problem with a technical owner. How long does it take to get a trivial change — a text correction, a configuration value — from merge to production? Measure it with a real change, not with an estimate. Then attack whatever dominates that number: manual deployment steps, environment provisioning, a test suite that takes a night to run, an approval that meets fortnightly. Every hour removed lowers the cost of releasing, and lowering the cost of releasing is what makes smaller batches rational. This is slow, unglamorous, and it is the work. trunk-based-development-and-why-it-matters and test-strategy-for-teams-that-ship-daily are the two capabilities that unlock most of it.

Replace the end gate with continuous assurance rather than removing it. The risk owner's gate goes away when they have something better, and not before. Automated security scanning, policy checks in the pipeline, evidence generated as a by-product of the build, and progressive delivery that limits blast radius are all more informative than a committee reviewing a document. Bring the risk owner into designing this. They usually know their gate is weak and will trade it for something stronger if they are treated as a partner rather than an obstacle.

Shrink the hardening phase deliberately, sprint by sprint. Do not abolish it by decree. Each time, ask what was found during it, and move the detection of that class of problem earlier — into the pipeline, into the definition of done, into the way environments are built. The phase shrinks as a consequence of the defects it used to catch being caught elsewhere. When it is a day, it is no longer a phase.

Then attack the front end, which is a funding and governance problem. Take one initiative and fund a team and a period rather than a scope and a date. Commit to an outcome — a measurable change in a business metric — and leave the feature list open. This is a much larger conversation than the release path, it requires a sponsor with real authority, and it is where the genuine transformation happens. Sequencing matters here; see sequencing-an-agile-transformation.

Move design into the build rather than before it. Keep the architectural thinking, discard the phase. Architects work alongside teams, decisions are recorded as they are made, and the design that is settled upfront is only the part that is genuinely expensive to change later. Everything else is deferred to the moment when there is evidence to decide with.

What to do on Monday

Take one change that shipped recently and build its timeline. The date the need was first raised, the date funding was approved, the date the specification was signed, the date the team started, the date they marked it done, the date it reached production. Put the six dates on one line and calculate the gaps.

Most people doing this for the first time find that the build phase is a minority of the elapsed time, and sometimes a small minority. Show that line to whoever is currently sponsoring an initiative to improve team-level agile practice. It is the most efficient argument available for redirecting that effort, because it is made entirely of your own dates.

Then pick the single largest gap and ask who owns it. If it is at the back end, you have a technical improvement with a named owner and you can start this week. If it is at the front, you have a governance conversation that needs a sponsor, and the timeline you have just built is the thing that gets you the meeting.