Water-Scrum-Fall: What It Is and Why It Happens

What is water-Scrum-fall?

Water-Scrum-Fall is a delivery model where waterfall-style planning surrounds an iterative development phase, followed by a sequential release and handover. The name describes the shape: water upstream, Scrum in the middle, fall downstream.

The important detail is where the lines fall. In a pure waterfall, everything is sequential. In a pure Scrum environment, discovery, delivery, and release all sit inside the same loop. Water-Scrum-Fall keeps the loop only for build work, which is precisely where change is cheapest to absorb and least valuable to learn from.

Where does the term come from?

Forrester analyst Dave West published “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today” on 26 July 2011, with Mike Gilpin, Tom Grant, and Alissa Anderson. The report argued that agile adoption had diverged from the Agile Manifesto’s original ideas, and that most adoptions resembled a hybrid the firm labelled water-Scrum-fall.

West had been observing teams across industries. In interviews from the period he described the pattern plainly: planning and release management were very waterfall-oriented, while development itself looked very much like Scrum. He also noted that the model is not automatically bad — the problem is deciding where the boundaries fall without thinking about the consequences.

The term stuck because it named something practitioners recognised but had no vocabulary for. Digital.ai’s 17th State of Agile report, based on 2023 data, found 71% of respondents using agile in their software development lifecycle while 42% described their organisation as using a hybrid model — 49% among large companies. The 18th edition put hybrid or homegrown approaches at 74%.

What are the three phases?

Read the table as a map of decision rights rather than of activities. The middle phase is where the team has authority; the outer phases are where the organisation keeps it. Most of the dysfunction comes from that mismatch, not from the ceremonies.

Why does water-Scrum-fall happen?

Water-Scrum-fall happens because five organisational systems run on annual or gate-based cycles, and only one of them — software delivery — can plausibly run on a two-week cycle.

Money is allocated annually. A budget approved in November cannot easily fund a discovery that changes direction in March. When the funding envelope is fixed before the problem is understood, the requirements get fixed too.

Contracts commit scope. Fixed-price and fixed-scope agreements require a defined deliverable, acceptance test, and date. Agile works by varying scope against fixed time and cost; a contract that varies nothing has to freeze requirements and manage change through amendments.

Regulation and risk require gates. In financial services, healthcare, and public sector work, production changes often need documented approval, segregation of duties, and evidence of testing. Those obligations are real. The mistake is implementing them as a weekly committee rather than as automated policy checks and peer review.

Governance runs on a committee cadence. Architecture boards, security reviews, and change advisory boards meet weekly, fortnightly, or monthly. A Thursday board imposes a Thursday-shaped delivery cadence.

The delivery team is the only group that adopted agile. Bottom-up adoption is how most transformations start. The team changes its own method and then finds its inputs and outputs still governed by processes it does not control.

> Common mistake: Treating water-Scrum-fall as evidence that the team is not “doing agile properly”. In most cases the team is doing exactly what its environment allows, and the environment is the thing that needs redesign.

Is water-Scrum-fall always a bad thing?

No. There are situations where a sequential envelope is the rational choice, and pretending otherwise produces worse outcomes than an honest hybrid.

If the work is genuinely well understood — a regulated data migration, a hardware-dependent rollout, a compliance deadline with a fixed statutory date — then committing scope early is defensible, because the cost of a wrong requirement is low and the cost of delay is high. If the supplier market requires fixed-price contracts, a waterfall envelope may be the only way to procure at all.

The honest version of the argument is about where learning is cheap. In software, most of the value of iteration comes from discovering that a requirement was wrong before you build the wrong thing. Water-Scrum-fall keeps that learning inside the build phase, where it can improve how you build but not what you build. If the “what” is stable, the loss is small. If the “what” is uncertain — the normal case for new digital products — the loss is the main event.

There is also a morale cost that rarely appears in the business case. Teams that demo working software every two weeks and then watch it queue for a quarter learn that their feedback does not matter.

What does water-Scrum-fall actually cost?

The cost shows up in three places: feedback latency, batch size, and queue time.

Feedback latency is the gap between learning something and acting on it. A discovery made in sprint three usually has to wait for a contract amendment, a change request, or the next planning cycle.

Batch size is how much change ships together. Quarterly releases bundle dozens of changes into one deployment, which makes failure harder to isolate, rollback riskier, and the blast radius larger.

Queue time is the waiting that never appears in a status report. Work that is “done” but not released is inventory. By Little’s Law, average cycle time equals work in progress divided by throughput, so anything that accumulates between phases lengthens delivery time even when every step is fast.

Worked example: a twelve-month programme

A programme has 10 weeks of discovery, business case, procurement, and architecture sign-off. Development runs 20 two-week sprints, or 40 weeks. System testing, UAT, change approval, and handover take another 6 weeks.

Total elapsed time: 56 weeks. Time inside the iterative loop: 40 weeks, or 71%. Time where a requirement change is cheap: effectively zero after week 10, because the contract and architecture are fixed.

Now suppose the team discovers in sprint 4 — week 18 — that a core integration cannot support the planned data volume. The workaround is known immediately. Acting on it requires a change request, a re-estimate, and a contract amendment with an average turnaround of five weeks. The team spends those five weeks building the version it now knows is wrong, because idling is not an option and the backlog was committed.

That single boundary turned a two-day design decision into five weeks of rework. Multiply it by the discoveries a normal programme makes in its first three months and the boundary, not the coding, becomes the dominant cost.

Worked example: the change advisory board queue

A delivery group submits 40 changes a month to a weekly change advisory board. Submissions close on Monday, the board meets on Thursday, and approved changes deploy in the next two-day window. Average wait from ready-to-deploy to deployed: 3.5 days to the board plus 2 days to the window, or 5.5 days.

Forty changes × 5.5 days = 220 change-days of waiting every month. If each change carries an average of two engineer-days of remaining work, the group holds roughly 80 engineer-days of finished inventory at any moment.

The board is not the villain. DORA’s 2019 Accelerate research found that external approval bodies were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate; organisations with formal external approval were 2.6 times more likely to be low performers. The same research notes that such boards typically approve the overwhelming majority of what they review, making them a delay rather than a filter.

How is it different from waterfall and from Scrum?

The distinction between water-Scrum-fall and agile-in-name-only matters. Water-Scrum-fall can produce real increments, demos, and technical improvement. Agile-in-name-only produces the vocabulary without the working software.

How do you tell whether you are in one?

Five tests, each answerable from artefacts rather than opinions.

1. Can a sprint demo change the scope of the next sprint? If the answer is “only through a change request”, you are in a water-Scrum-fall.
2. How long between “done” and “in production”? Measure the median. Anything above two weeks for routine changes indicates a gated fall.
3. Who can say no to a requirement after development starts? If nobody below the steering committee can, the water boundary is hard.
4. What is the release batch size? More than roughly ten changes per release means batching is driving risk.
5. Does the definition of done include deployment? If “done” means “passed UAT”, the team does not own the outcome.

Score each from 0 to 2 and sum. A score of 7 or above means the boundaries are doing most of the damage; below 4 means the hybrid is probably working as intended.

How do you fix the water boundary?

Fix the water boundary by separating discovery from commitment. The goal is not to remove the business case or the contract; it is to make sure the thing being committed is a problem and a budget, not a frozen solution.

Run discovery before the gate, not inside the build. A four- to six-week discovery with real users, a technical spike, and a costed options paper produces better commitments than a requirements document written by people who will not build it. Fund discovery as its own small budget line so it does not need a full business case to start.

Commit time and money, vary scope. A fixed budget with a prioritised backlog and an explicit scope-exchange rule is compatible with most finance processes. The trick is naming the trade-off in the contract: “if we add X, we remove Y or extend by Z weeks” beats “all requirements are mandatory”.

Rewrite the requirement as an outcome. “Reduce onboarding time from nine days to two” survives contact with reality better than “build a five-step wizard”. Outcomes give the team room to learn without breaching the contract.

How do you fix the fall boundary?

Fix the fall boundary by shrinking the distance between “done” and “live”. Four levers do most of the work.

Decouple deploy from release. Ship code to production behind a feature flag, then decide when to expose it. Deployment becomes routine and low-risk; release becomes a business decision rather than a technical event.

Classify changes by risk, not by paperwork. Standard, low-risk changes should flow through a pre-approved path with automated checks. Reserve the board for genuinely high-risk changes: irreversible data migrations, cross-system infrastructure shifts, regulatory-sensitive releases. DORA’s finding is not that governance is bad; it is that uniform external approval slows delivery without improving stability.

Automate the evidence. Test results, approval records, and deployment logs generated by the pipeline satisfy segregation-of-duties requirements better than meeting minutes, because they are complete and tamper-evident.

Extend the definition of done to include production. If it stops at “passed UAT”, the release is somebody else’s problem and nobody optimises for it. Including deployment, monitoring, and rollback changes what the team designs for.

> Practical tip: Pick one routine change type — a copy update, a configuration tweak, a minor dependency bump — and measure its end-to-end lead time for a month. That single number is the most persuasive argument for reform you will find, because it converts a cultural argument into a queue.

What if you cannot change the gates?

Sometimes you cannot. The regulator, the client, or the parent company will not move, and the release gate stays. In that case, optimise inside the constraint rather than pretending it does not exist.

Three moves work. First, front-load the risky learning: spend the first two sprints on the integrations, data, and assumptions most likely to invalidate the plan. Second, pre-negotiate the change mechanism: agree in advance how a change request will be priced and how fast it will be decided. Third, make the queue visible: publish the age of every item waiting for approval, because invisible queues are tolerated and visible ones get fixed.

Where does Doitify fit?

Water-Scrum-fall is a boundary problem, and boundaries are easier to manage when work on both sides is visible in one place. Doitify combines sprints and backlogs, WBS dependencies, roadmaps, Gantt charts, milestones, and workload views with task-level status, so a discovery made mid-sprint can be traced to the requirement, the milestone, and the release it affects.

Doitify Copilot can help turn a goal or a change request into structured tasks, sub-tasks, and checklists, shortening the loop between “we learned something” and “here is the adjusted plan”.

Full transparency: Doitify is our product. It will not move a regulator, rewrite a fixed-price contract, or persuade a change board to meet daily. What it can do is make the cost of the boundary visible, which is usually the precondition for changing it.

What are the most common mistakes?

• Adding ceremonies instead of moving boundaries. More backlog refinement inside a frozen scope produces better-documented rework.
• Blaming the team for a governance constraint. The team cannot fix an annual budget cycle by estimating better.
• Treating the release gate as a quality step. Gates that approve more than 90% of what they see are delays, not filters.
• Measuring velocity without measuring lead time. Velocity says how fast the middle moves; lead time says how long the whole thing takes.
• Calling it agile in public. The gap between the label and the reality destroys trust faster than an honest hybrid ever would.

Conclusion

Water-Scrum-fall is not a failure of discipline. It is what happens when an iterative team sits inside sequential funding, contracting, and release systems, and nobody redesigns the seams.

The middle can stay Scrum. The work is at the edges: discover before you commit so the plan can absorb what you learn, and shorten the distance between done and live. Teams that fix the seams get the benefit of iteration. Teams that only add ceremonies get a better-documented version of waterfall.

If this post on water-scrum-fall was helpful, you might also enjoy Project Dashboard Examples: 10 Dashboards That Keep Projects on Track and Project Documentation: The Complete Guide (Types, Examples, and Best Practices).