Every sprint is a mini-waterfall. Every Kanban board is a view of Waterfall’s middle phases. The debate assumes teams chose either Agile or Waterfall. Most teams are running both — and the methods don’t describe what they’re doing.
The Agile vs. Waterfall debate has run for two decades. The premise is that teams face a choice: plan everything up front, or iterate in short cycles.
The data says the choice was never made. The 16th Annual State of Agile Report found that 50% of organizations use a combination of Agile, Waterfall, and iterative methods — and 24% use Waterfall alone. Read together, that means Waterfall appears in at least a quarter of cases and as much as three-quarters, depending on how much of the hybrid group includes it.
Waterfall isn’t a method teams abandoned. It’s one they kept.
Digital.ai‘s 18th State of Agile Report — based on a survey of roughly 350 respondents, mostly Agile coaches and consultants at large enterprises — found that 74% use hybrid, blended, or homegrown models. The category has a new name. The practice underneath it hasn’t changed.
That’s not indecision. It’s evidence that neither method describes the work.
The gap between what methods claim and what teams do
Every method has an ideal. And in every case, the practice doesn’t match it.
| Method | What it claims | What happens in practice |
|---|---|---|
| Scrum | Iterative delivery in short cycles | Sequential work inside each sprint |
| Waterfall | A planned, sequenced delivery | The plan locks, and delays cascade |
| Kanban | Continuous flow with pull | The cards come from a decomposition the board can’t see |
This isn’t because teams execute badly. It’s because the methods describe a world that isn’t the one teams work in. So teams improvise — and the improvisation is invisible.
Scrum vs. Waterfall: a false choice
A team says it runs Scrum. Look inside a sprint, and the work is sequential: design, then build, then integrate, then test. One pass, in order.
Two weeks isn’t enough to do all four at once. So the work is sized to fit the calendar — and each sprint becomes a mini-waterfall inside a Scrum container. Scrum provides the cadence. Waterfall provides the shape.
Scrum.org itself addresses this. They have an article titled Developing in One Sprint and Testing in the Next Is Not Scrum — describing teams that split development and testing across sprints, a pattern the community calls water-scrum-fall. The community recognizes this hybrid, and Scrum.org warns it “causes more problems than it solves.”
The combination produces a predictable failure. The phases must fit the calendar, not the work. So the team takes the shortcuts that make day 14. Those shortcuts are the debt — unrecorded, unlocated, unscheduled. The next sprint adds more on top. The board stays green while the system quietly becomes harder to change.
Consider the problem everyone recognizes: integration testing gets squeezed against the delivery date, because APIs aren’t ready until late. The sprint boundary doesn’t know about the dependency. The team commits to the story, discovers the gap, and the sprint still ends on day 14.
This is not a discipline problem. It’s what the structure is designed to do.
Kanban vs. Waterfall: a category error
The second debate is stranger, because Kanban and Waterfall aren’t doing the same job.
Waterfall structures the plan and sequences dependencies. Kanban shows flow — what’s in progress, where work is stuck. One tells you what order to build in. The other tells you what’s moving. Treating them as rivals is a category error.
But the deeper point is where the cards come from.
Where the cards come from
Cards don’t appear from nowhere.
A system is built by multiple people working on different parts. If different people work on different things, the system has been divided into parts. And those parts are what the cards represent.
So the cards are the result of a division. That division is a decomposition.
And decomposition is a design activity. You can’t build the pieces until you know what the pieces are. Design precedes construction — which is Waterfall’s defining sequence, whatever else Waterfall includes.
Now look at what the board shows. Columns for states. Cards moving between them. What it doesn’t show: how the system was divided, why it was divided that way, or whether the division respects the system’s actual components.
That decision happened off-board. It happened upstream, in refinement or planning or someone’s head. The board shows the result of the decision. It shows none of the reasoning.
So Kanban isn’t a replacement for Waterfall. It’s a view of one part of it. Requirements and design happened upstream. The board shows construction — and verification, if testing is tracked separately. It’s a window onto Waterfall’s middle phases.
What this produces
If the decomposition followed the system’s structure — components, dependencies, boundaries — the cards are coherent. The pieces fit. Construction proceeds against a design that holds.
If the decomposition was arbitrary — cut by size, by effort, by what fits on a sticky note — the cards fragment the system along lines that don’t match it. The pieces don’t correspond to anything real.
And that’s where debt accumulates. Not in the code, but in the interfaces between pieces that were never designed to fit. The mismatch lives in the boundaries nobody owns — and no board shows it, because the board only shows the pieces.
The debt isn’t caused by a bad sprint or a careless developer. It’s caused by a decomposition that was never designed, applied to a system that needed one.
What Albatross does instead
Albatross starts with the design that both methods leave implicit.
Structure is designed before construction. Components with named owners. Dependencies as a DAG. Major data flows and the data items they carry. This is the decomposition — made explicit, made visible, made the first step rather than an invisible one.
The schedule is plotted from that structure. Dates come from dependencies, not from past velocity. Critical paths are visible. When a path threatens to elongate, the plan is corrected — decompose further, reallocate, reorder — before it becomes a crisis.
Debt is located during design. Debt confined to a bounded component can be repaid without destabilizing the system. Debt that has spread into the interfaces can’t — it can only be replaced. So the design records where debt sits and when it will be repaid.
The plan doesn’t reset at a calendar boundary. A phase ends when the work is done, not when a date arrives. So a decision made in month one can still be in force in month three — because nothing threw it away at the sprint boundary.
This isn’t Scrum plus Waterfall. It’s not a hybrid, and it’s not a compromise. It takes the sequence from Waterfall and the responsiveness from Agile, and discards what breaks each: the calendar cut from one, the phase lock from the other.
The choice was never real
Teams were told to choose between two methods. They chose both — and the combination doesn’t describe what they’re doing either.
Scrum’s cadence forces sequential work into a calendar container. Waterfall’s sequence locks a plan that reality will change. Kanban shows the result of a decomposition it can’t see. None of them describes the structure of the system being built.
That’s the actual problem. Not which method to pick — but that the structure of the work has no home in any of them.
The methods don’t describe the work. That’s why the debate never resolves.
Related:
- Why Tech Debt Never Gets Repaid — It’s Not Visibility, It’s Incentives
- The Albatross Method as a Structural Fix for Tech Debt
Sources:
- 16th Annual State of Agile Report — hybrid and Waterfall adoption figures
- Digital.ai press release, 18th State of Agile Report — hybrid, blended, and homegrown models (n≈350, skewed toward Agile coaches at large enterprises)
- Scrum.org — Developing in One Sprint and Testing in the Next Is Not Scrum