Hybrid Models: Agile Inside Waterfall, Waterfall Inside Agile

Water-Scrum-FallWater-Scrum-Fall describes a hybrid that mostly happens by accident — organisational constraints leave a waterfall shell around a genuine Scrum core, without anyone designing it that way on purpose. This page covers the two hybrids teams build on purpose, because each solves a real problem the pure form of its parent methodology does not.

Agile-within-Waterfall

InIn this pattern, the project as a whole is governed by waterfall-style stage gates — typically because a regulator, a funding body, or a large enterprise's own portfolio-governance process requires them. Each gate is a discrete, documented milestone: business case approved, requirements baselined, design approved, implementation complete, acceptance tested, deployed. What changes is what happens inside the "implementation" gate: rather than a single long coding phase, that gate is internally organised as a sequence of agile sprints, each producing a working increment that is reviewed and integrated before the gate as a whole is declared complete.

This is extremely common in regulated and government contracting, where the contract itself has to specify fixed milestones and payment triggers (a waterfall requirement external to engineering), but the supplier is free to organise the actual build work sprint by sprint to manage risk and get earlier feedback on individual features. The stage gates function as a form of risk control at the portfolio level — see Risk Management for the general principle that a gate exists to catch a specific category of risk before it compounds — while the sprints inside each gate provide the finer-grained risk control of iterative delivery.

Waterfall-within-Agile

TheThe mirror-image pattern runs the other way: the project is agile in its ongoing delivery mode, but begins with an upfront phase — often literally called "Sprint 0" or a discovery phase — that is run in a waterfall style: gather and document requirements, settle the target architecture, agree the technology stack and major integration points, size the overall effort. Only once that groundwork is done does the project switch into an ongoing cadence of agile sprints delivering working software.

This pattern exists because some decisions genuinely are cheaper to make once, upfront, than to discover incrementally — a database platform choice, a regulatory data-residency constraint, an integration contract with an external system that a dozen teams will depend on. Treating those as agile-discoverable "just build a bit and see" decisions can be far more expensive to unwind later than spending a bounded discovery phase settling them first. The risk is that "Sprint 0" quietly grows into a full waterfall requirements phase that never actually hands over to agile delivery — a failure mode worth naming for exactly the reason Water-Scrum-Fall discusses: process labels are cheap, and it is the underlying structure that determines what a team is actually doing.

Scaled Agile: SAFe as Institutionalised Agile-within-Waterfall

LargeLarge organisations running dozens of agile teams against a single product or portfolio have generally not been well served by "just run more Scrum teams" — coordinating dependencies, budgets, and release trains across that many teams needs its own structure. The best-known answer is the Scaled Agile Framework (SAFe), created by Dean Leffingwell and first released in 2011, building on ideas from his earlier books Scaling Software Agility (2007) and Agile Software Requirements (2010)¹. SAFe layers portfolio-level planning, fixed-length "Program Increments," and formal governance roles on top of team-level Scrum or Kanban — in effect, it is agile-within-waterfall made explicit and standardised: the enterprise keeps portfolio-level planning cadences and governance gates that look distinctly waterfall-shaped, while the delivery teams inside that structure run genuine agile sprints. SAFe is not one of the four core frameworks this series covers in depth, but recognising it as a formalisation of a pattern already covered above — rather than a wholly separate paradigm — is enough to place it correctly when it comes up in industry conversation.

Reading the Reality

BetweenBetween this page and "Agile-Inspired": The Water-Scrum-Fall Reality, the point to take away is the same one in two forms. Every real project sits somewhere on a spectrum between pure waterfall and pure agile, and the honest question is never "which methodology are we using" but "which decisions here genuinely benefit from being made early and fixed, and which genuinely benefit from being deferred and discovered iteratively." Water-scrum-fall is what happens when that question is never asked and the answer is inherited by accident from whatever structures already existed. Agile-within-waterfall and waterfall-within-agile are what happens when it is asked deliberately and the hybrid is designed on purpose. Choosing a Methodology turns this into a practical decision process for a real project.

References