Enterprise Agile scaling fails in predictable ways. After enough PI Plannings, ARTs, and transformation programmes, the same dysfunctions appear regardless of which framework the organisation chose. Here are the seven most common failure patterns — and the interventions that actually fix them.
Pattern 1: WaterScrumFall
What it looks like: Requirements are defined in a 3-month "analysis phase," then handed to Scrum teams who run sprints but cannot change scope, then the output goes through a 6-week "hardening phase" before release.
Why it happens: Leadership wants Agile speed but Waterfall predictability. The result is neither.
Fix: Move requirements into the backlog from the start. Embed discovery in the delivery team. Eliminate handoff phases by making the DoD include production deployment.
Pattern 2: Fake PI Planning
What it looks like: PI Planning runs for two days, teams produce PI Objectives and a Programme Board — but the roadmap was already fixed by management three months before. PI Planning is a presentation, not a planning event.
Why it happens: Leadership uses Agile vocabulary for a Waterfall process to appear modern.
Fix: Genuine PI Planning requires that the backlog going into the event is NOT fully fixed. If programme leadership won't allow teams to change the plan, the PI Planning is a status meeting. Name this honestly and escalate.
Pattern 3: Velocity Theatre
What it looks like: Teams report velocity metrics week-over-week with steady improvement — while sprint goals are routinely missed and customer outcomes stagnate.
Why it happens: Teams optimise for the metric they are measured on. If management measures velocity, teams inflate estimates.
Fix: Replace velocity as the primary metric with outcome-based measures: throughput (items shipped), cycle time, customer satisfaction, and sprint goal achievement rate.
Pattern 4: Dependency Gridlock
What it looks like: The Programme Board at PI Planning is covered in dependency arrows. By Sprint 3, most of them have become blockers. Teams sit idle waiting for another team's output.
Why it happens: Component team structures create inherent dependencies that no amount of coordination can fully resolve.
Fix: Restructure toward feature teams that own end-to-end capability delivery. Where component teams persist, create a Platform Team that provides internal services with published SLAs rather than sprint-level commitments.
Pattern 5: Ceremony Inflation
What it looks like: Teams spend 40–50% of their sprint in meetings. Standups run 30–45 minutes. PI Planning is three days. Sprint planning takes a full day. The team barely has time to deliver.
Why it happens: Ceremonies grow without governance. Every stakeholder wants their issue on the agenda. Nobody challenges meeting length.
Fix: The SM owns ceremony health. Timebox every event strictly. Run a time audit: calculate the total person-hours in ceremonies per sprint and present it to the team. Typically teams are shocked by the number and self-correct.
Pattern 6: Absent Product Ownership
What it looks like: The PO is unavailable for refinement, attends sprint planning for 20 minutes, and accepts sprint output via email rather than in the sprint review. Teams build features that nobody wanted.
Why it happens: PO is over-stretched across multiple teams, or the role has been assigned to someone without authority to prioritise.
Fix: One PO per team is the Scrum Guide minimum. If a PO is working across three teams, they are not a PO — they are a backlog administrator. Escalate the structural problem. A proxy PO arrangement is better than an absent real one.
Pattern 7: The Agile Facade
What it looks like: The organisation uses all the Agile vocabulary (sprints, backlogs, standups, retros) but funding is still project-based, teams are still disbanded at "project end," and annual planning still fixes scope 12 months out.
Why it happens: Leadership adopted Agile practices without changing the underlying funding and governance model.
Fix: This is the hardest pattern to fix because it requires changing how money flows — typically a CFO-level decision. SMs can build the business case using total cost of delay data: how much value is destroyed by the current funding model's inflexibility. Lean Portfolio Management (LPM) is the framework for changing this at enterprise level.