Nobody designs Water-Scrum-Fall. It grows. A company reads about agile, puts a few teams through Scrum training, and declares that they're "going agile" — while leaving the annual budgeting process, the fixed-scope contracts, and the quarterly release windows exactly as they were. The result is a process that looks agile at the team level and feels Waterfall at every other level.
Water-Scrum-Fall is sometimes a criticism and sometimes just an accurate description. This lesson helps you see it clearly, without either romanticising agile transformation or dismissing the real constraints that create hybrid processes.
Learning Objectives
- Define Water-Scrum-Fall and explain how it typically forms
- Describe the three layers of Water-Scrum-Fall (Waterfall planning, Scrum execution, Waterfall release)
- Explain why Water-Scrum-Fall is not inherently a failure
- Identify the specific pain points that Water-Scrum-Fall creates for QA and BA roles
The Three Layers
Water-Scrum-Fall has three identifiable layers, each with a different process:
Layer 1: Waterfall Planning (Top)
At the top, the organisation plans in a traditional waterfall mode:
- Annual budget cycle determines what projects get funded
- Requirements and scope are defined upfront (or at least in a discovery phase before development begins)
- Delivery dates are committed to stakeholders and sometimes contractually locked
- Success is measured by delivering the committed scope on time and on budget
Who operates here: Executives, project sponsors, PMO, procurement, legal
For BA: Many Business Analysts are caught in this layer — expected to produce detailed requirements documents months before the team starts building. This creates a "requirements freeze" that conflicts with the agile principle of responding to change.
Layer 2: Scrum Execution (Middle)
In the middle, development teams run Scrum (or something like it):
- Two-week sprints with all the standard ceremonies
- Product backlog managed by Product Owner
- User stories, estimation, velocity tracking
- Continuous integration and automated testing
Who operates here: Development teams, QA engineers, embedded BA, Scrum Masters, Product Owners
This is where agile is genuinely practised — but within constraints set by Layer 1 and enforced by Layer 3.
Layer 3: Waterfall Release (Bottom)
At the bottom, releasing software is a heavyweight, bureaucratic process:
- Change Advisory Board (CAB) must approve every production release
- Release windows are quarterly or less frequent
- A separate operations or release management team owns the deployment
- Release testing (UAT, regression, compliance) is a separate, long phase
Who operates here: Release management, operations, compliance, CAB members
For QA: Many QA engineers find themselves caught between Layer 2 (embedded in agile teams, doing continuous testing) and Layer 3 (expected to execute a formal regression test phase before each quarterly release). These two testing expectations are incompatible without deliberate process design.
Why Water-Scrum-Fall Exists (and Persists)
Water-Scrum-Fall is not a mistake that can be easily fixed. It exists for real reasons:
1. Financial governance: Organisations must approve expenditure. Annual budgets are a governance mechanism, not a bureaucratic preference. Moving to product-based funding (a team owns a product area with a recurring budget) requires executive and finance team alignment that takes years.
2. Contractual obligations: Many organisations deliver software to external clients under fixed-price contracts. These contracts define scope, price, and delivery date upfront. No amount of agile enthusiasm changes a signed contract.
3. Regulatory compliance: Heavily regulated industries (banking, healthcare, aviation) have release and change management requirements mandated by regulators. A quarterly release window isn't a choice — it's a regulatory requirement.
4. Risk appetite: Large organisations are often risk-averse. Frequent, small releases are statistically lower risk — but they feel riskier to risk committees than infrequent, heavily-tested releases.
The Pain Points for QA
Water-Scrum-Fall creates specific tensions for QA engineers:
| Problem | Layer 1 cause | Layer 3 manifestation |
|---|---|---|
| QA has two jobs | Scope locked upfront | Both continuous and UAT testing required |
| Test environment chaos | Budget approved once, shared forever | Pre-release environments are always contended |
| "Testability" is never designed in | Requirements defined before QA involvement | QA discovers untestable requirements at Layer 3 |
| Regression takes weeks | Quarterly release accumulates too many changes | Manual regression is the only option |
Pro Tip: The most effective intervention a QA can make in Water-Scrum-Fall is to participate in Layer 1 requirements discovery, not just Layer 2 sprint testing. If you can identify testability issues (missing acceptance criteria, ambiguous edge cases, environmental dependencies) during the requirements phase, you save weeks of pain at the Layer 3 testing phase. "Shift left" is not just a buzzword — in Water-Scrum-Fall, it's survival.
Summary
- Water-Scrum-Fall emerges organically when agile teams operate within traditional Waterfall governance and release structures
- It has three distinct layers: Waterfall planning (top), Scrum execution (middle), Waterfall release (bottom)
- The pattern exists for real organisational reasons — financial governance, contracts, compliance, risk appetite
- For QA, the key pain points are the dual testing expectation and the late discovery of testability issues
- Understanding why Water-Scrum-Fall exists is the prerequisite for navigating it effectively