"Agile-Inspired": The Water-Scrum-Fall Reality

EverythingEverything taught in Agile Origins and Scrum describes a coherent, self-consistent way of working. Very few students will graduate into a company running it in that pure form. This page is about the gap between the two — not to be cynical about Agile, but because walking into a job expecting textbook Scrum and finding something else is a bigger shock than expecting the something else in the first place. It is worth reading alongside Waterfall, because the pattern here is best understood as waterfall's structure surviving underneath an agile-labelled surface.

The Term: Water-Scrum-Fall

Water-Scrum-Fall"Water-Scrum-Fall" was coined by Dave West of Forrester Research in a July 2011 trend report, "Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today"¹. West's report was intended as a warning about organisations doing agile only half-way — but the label stuck as a neutral description of the pattern, and West is now generally credited with naming an approach he was actually cautioning against².

The pattern it names has three layers:

Stage	What actually happens	Why it stays waterfall-shaped
Upfront ("Water")	Requirements gathering, high-level architecture, budget approval, often a business case with a fixed scope and cost	Funding and procurement processes need a number to approve before anything can start; you cannot put "we'll find out as we go" in front of most finance committees
Middle ("Scrum")	Sprints, standups, backlogs, sprint reviews — real agile ceremonies, run for real	This is the part organisations actually adopted, because it can be bolted onto an existing team without changing anything above or below it
Downstream ("Fall")	A formal release process, staged environments, change-advisory boards, compliance sign-off, a scheduled go-live	Regulatory, security, and audit requirements are frequently written around discrete release events, not continuous deployment

The middle layer is real agile practice. The organisation is not lying when it says it "does Scrum." What it has not done is restructure the funding model or the release/compliance process around continuous, incremental delivery — because those structures were not built by the engineering team and are usually outside the engineering team's authority to change.

The Evidence for the Gap

ThisThis is not a fringe observation. Digital.ai's annual State of Agile Report, one of the longest-running industry surveys of agile adoption, has repeatedly found a widening gap between organisations that report using agile practices and organisations that report those practices are actually delivering the outcomes they promise. The 18th edition (2025) found agile-culture satisfaction slipping to 59% of respondents, with only 27% saying their agile culture is genuinely enabling value and a further 42% describing it as "better than nothing, but could be more effective"³. The same report found 63% of respondents still struggle to deliver reliable, high-quality software — up twelve points on the previous year — and 73% wanting stronger leadership alignment between delivery work and business goals³. Read across the report's history, the consistent finding is not that agile adoption is rare — most software organisations claim some form of it — but that depth of adoption lags claimed adoption: ceremonies spread faster than the organisational changes (funding, governance, release process) that would let those ceremonies deliver their full promised benefit.

Why This Happens — Not Simple Failure

ItIt is tempting to read water-scrum-fall as teams doing agile badly. That is rarely the real cause. The pattern is a rational response to constraints most engineering teams do not control:

• Fixed-budget procurement. Public-sector and large enterprise contracts are frequently procured against a fixed scope, price, and delivery date agreed before any sprint runs. Whatever happens inside delivery, the contract itself is waterfall-shaped, because procurement law and vendor risk management were not written with iterative discovery in mind.
• Compliance and audit requirements. Regulated industries (finance, health, aviation, government) often have externally imposed sign-off gates — a security accreditation, a clinical safety case, a change-advisory board — that exist as discrete, documented events. Continuous deployment does not remove the regulatory requirement; it just makes the gate harder to schedule around.
• Organisational structure. A Scrum team can restructure its own daily work far more easily than it can restructure the finance department's approval cycle, the security team's review calendar, or a separate infrastructure team's own release schedule. Agile transformation efforts frequently agile-ify the part of the organisation closest to the code and stop at its boundary.
• Career and incentive structures. "Looking agile" — running the ceremonies, using the vocabulary, showing a burndown chart — is often what gets rewarded and audited, independent of whether the ceremonies are changing outcomes. This creates a real incentive to adopt the visible layer of Scrum without touching the less visible, harder-to-change layers above and below it.

None of this means Agile "doesn't work." It means Agile's original promises were made about a full restructuring of how software gets funded, governed, and released — and most organisations have only restructured the part in the middle. Recognising water-scrum-fall for what it is — a structural compromise, not a personal failure by the team running the standups — is what lets you work effectively inside it rather than being disillusioned by it.

The next page, Hybrid Models, names the two genuinely different ways organisations combine waterfall and agile deliberately, rather than by accident. Choosing a Methodology then covers how to reason about which structure fits a given project's real constraints.

References