April 2026 12 min read Opinion
There is a category of organisational state that does not have a clean name but that most Agile practitioners encounter regularly. The organisation runs sprints. It has Scrum Masters and Product Owners. It talks about value delivery, empirical process, and iterative development. It has Agile on the wall and in the org chart. And it makes decisions the way it always has: hierarchically, slowly, and based on upfront plans that exist before any work begins.
Call it Agile Waterfall. The vocabulary is Agile. The authority structure is not.
The Hook: The Most Expensive Kind of Transformation
Genuine Agile transformation is difficult and expensive. It requires changing not just processes but decision-making structures, authority distributions, and organisational expectations about how work happens. Many organisations want the outcomes of Agile without the structural changes that make those outcomes possible.
The result is Agile Waterfall: a transformation that completes the vocabulary acquisition but stops short of the authority transfer. The ceremonies exist. The roles exist. The language is correct. But the Product Owner cannot reprioritise the backlog without a Change Advisory Board approval. The Scrum team cannot make architectural decisions without going through the Architecture Review Board. The team cannot commit to a sprint scope without the project manager validating it against the original project plan.
None of these authority constraints are compatible with Agile. All of them are features of Waterfall governance that survived the transformation because changing them was too politically difficult. The organisation got the language of Agile and kept the structure of Waterfall. This is not a partial transformation. It is an expensive charade.
The Reality: Where the Authority Gaps Are
Agile Waterfall is not random. The authority gaps cluster in predictable places.
The Product Owner Who Cannot Own
The Product Owner role, as defined in the Scrum Guide, requires genuine authority to manage the backlog and make trade-off decisions about product direction. In most organisations that have adopted Scrum, this authority is divided among multiple stakeholders, approval processes, and steering committees.
The Product Owner in these organisations is a facilitation role rather than a decision-making role. They gather requirements, communicate between the development team and the business, and represent backlog items at ceremonies. What they do not do is make authoritative decisions about what the product should do next. Those decisions go to a committee, to a project steering board, to a senior stakeholder who was not included in the Scrum adoption.
The result is a Product Owner who is accountable for outcomes they do not control and who spends significant time navigating approval processes for decisions the Scrum framework assumes they can make directly. The role exists in the org chart and does not exist in the actual authority structure.
The Sprint That Is Not a Sprint
A sprint, in Scrum, is an event in which the team commits to a Sprint Goal and makes the decisions necessary to achieve it. The team adapts daily based on new information. The sprint scope can change if circumstances change and the Product Owner and team agree.
In Agile Waterfall, the sprint is a two-week segment of a pre-existing project plan. The scope was determined before the sprint started, in the project plan that was approved before development began. The team does not commit to a Sprint Goal – they commit to delivering the items that the project plan says should be done in this sprint. Adaptation is not welcome, because the project plan does not have a mechanism for adaptation.
This is not iterative development. It is waterfall development segmented into fortnightly batches and renamed. The project manager can report that the organisation is running Agile sprints. The sprints are delivering against a fixed plan in fixed increments, which is waterfall behaviour with Agile vocabulary.
The Architecture That Cannot Be Changed
Technical decisions in many organisations require architectural review processes that operate on a different timescale than Agile development. An architectural decision that emerges from sprint work – a need to refactor a component, a technology choice that affects the product direction, an integration approach that needs to change based on what the team has learned – requires a formal review process that takes weeks or months.
The team cannot act on what they learn, because the governance structure that applies to technical decisions was designed for a world where decisions were made once, at the beginning of projects, and implemented without revision. The Agile framework assumes that technical decisions can be made incrementally and revised based on feedback. The governance structure makes this impossible.
The team learns that certain types of decisions are blocked and stops making them. The technical direction of the product freezes into the early architectural choices, regardless of what the team has learned since. This is how Agile development teams accumulate technical debt at waterfall pace.
The Checksum: What Genuine Authority Looks Like
The difference between Agile and Agile Waterfall is not vocabulary or ceremony. It is where authority to make decisions about work actually sits.
Genuine Agile development requires authority at three levels: product authority (what should be built), process authority (how the team works), and technical authority (how the product is built). In genuine Agile, all three are held close to the work – by the Product Owner, by the team, and by the developers and architects doing the work.
Agile Waterfall preserves these authorities at the management and governance layer while transferring the vocabulary to the execution layer. The team talks about Agile. The organisation decides in waterfall.
“Agile Waterfall is what happens when an organisation wants the productivity of decentralised decision-making and retains the control of centralised decision-making. You cannot have both. You get neither.” Markus – agile-checksum.com
The Authority Audit
The simplest test for Agile Waterfall is the authority audit. For each of the following decisions, identify who actually has the authority to make them:
- Can the Product Owner remove a planned feature from the sprint without escalation?
- Can the team change its technical approach mid-sprint based on new information?
- Can a developer refuse to implement something that they believe creates significant technical debt?
- Can the Scrum Master cancel a ceremony that is not producing value?
- Can the team decline additional scope from a stakeholder during a sprint?
If the answer to most of these is “it depends on approval” or “they would need to check with management,” the organisation is running Agile Waterfall. The authority structure has not changed. Only the vocabulary has.
Real-World Case Studies
The Approval Sprint
A financial services organisation had adopted Scrum across its technology department. Every team ran two-week sprints with all the standard ceremonies. The teams were enthusiastic and skilled. The Scrum Masters were excellent facilitators.
When I examined the decision flow for a typical product change, I found a governance layer that was entirely invisible in the Agile adoption documentation. Any change affecting a customer-facing feature required approval from a Change Advisory Board that met fortnightly. Any architectural change required an Architecture Review Board submission with a four-week lead time. Any change to the product roadmap required approval from the Programme Management Office that governed all projects.
The teams were running Agile ceremonies on a two-week cadence and making decisions on a four-to-eight-week governance cycle. The sprint backlog was not the Product Owner’s decision. It was the output of the governance cycle that preceded it. The Agile adoption had added overhead without changing anything that mattered for decision-making speed.
The Project Manager Under a Different Title
A technology company had transitioned to Agile three years previously. The role of Project Manager had been renamed Product Owner. The responsibilities had not changed. Product Owners maintained project plans, reported to steering committees, and managed scope against original estimates.
When I asked one of the Product Owners to describe their most recent backlog reprioritisation decision, she described a process that involved three stakeholder consultations, a business case update, a steering committee presentation, and a two-week approval cycle. The reprioritisation had been straightforward and valuable. The process had taken six weeks.
The organisation had been running Agile for three years. The speed of product decision-making had not changed since before the adoption. The vocabulary had changed completely. The authority structure had not changed at all.
What Genuine Transformation Requires
Agile Waterfall is not primarily a technology problem or a process problem. It is a governance problem. It persists because the authority transfer that genuine Agile requires is politically difficult. Giving teams real authority to make product decisions, technical decisions, and process decisions means that management layers that previously held those authorities must release them. This is not a technical change. It is a power change.
The organisations that succeed at genuine Agile transformation are the ones where senior leadership understands that the authority transfer is the transformation – not the vocabulary change, not the ceremony adoption, not the tool implementation. Everything else is scaffolding.
For Transformation Leaders
- Do the authority audit before the ceremony adoption. Understand where decision-making authority actually sits before implementing Agile roles and ceremonies. The gap between where Agile needs authority to sit and where it currently sits is the actual scope of the transformation.
- Name the governance conflicts explicitly. The Change Advisory Board, the Architecture Review Board, the Programme Management Office – these are not problems to work around. They are constraints that make Agile behaviour impossible. Name them, negotiate them, or acknowledge that the transformation will be theatre.
- Measure decision speed. How long does it take from a team identifying a needed change to that change being implemented? If the answer is weeks or months, the governance structure has not been touched by the Agile adoption. This is the measurement that reveals Agile Waterfall most clearly.
The Takeaway: The Vocabulary Is Not the Transformation
Adopting Agile vocabulary while retaining Waterfall authority structures produces an expensive and demoralising outcome. Teams are accountable for results they cannot influence. Product Owners hold responsibility without authority. Scrum Masters facilitate ceremonies that cannot produce change because the change authority does not live in the ceremonies.
Run the checksum on your transformation:
- When did your Product Owner last make a significant product decision without going through an approval process? How long did it take?
- How long does it take from a team identifying a technical problem to having the authority to solve it?
- If you removed the Agile vocabulary from your organisation – the sprints, the ceremonies, the role names – would the actual decision-making behaviour be recognisably different from what it was before the transformation?
The answer to the third question tells you everything.
Glossary Terms Used in This Article
- Agile Transformation – The process by which an organisation attempts to adopt Agile values and practices at scale.
- Product Owner – The Scrum accountability responsible for maximising the value of the product.
- Backlog – An ordered list of everything that might be done in the product.
- Technical Debt – The implied cost of rework caused by choosing an expedient solution over a better approach.
- Sprint – A Scrum event with a fixed time period in which a usable product increment is created.
No Fluff. Just Real Agile.
Straight to your inbox. No buzz, no spam.
Related Articles
"Retrospectives That Generate Insight but Not Change"
Teams that run retrospectives diligently and change nothing are not failing at retrospectives. They are succeeding at a different activity entirely – one that looks like continuous improvement but produces none.
Read Article →"Scrum Theatre: Why the Daily Becomes a Status Meeting"
The Daily Scrum is the most observed ceremony in Agile. It is also one of the most consistently misused. Here is why it degrades into a status report – and what the structure actually requires.
Read Article →"What Good Backlog Refinement Actually Looks Like"
Not a ceremony. Not a grooming session. A discipline that determines whether Sprint Planning takes ninety minutes or four hours. Most teams do refinement wrong – not because they lack technique, but because they misunderstand the purpose.
Read Article →