A single agile team, given a clear backlog and reasonable autonomy, is one of the most reliable delivery mechanisms in software. Give that same team's practices to fifty teams working on an interdependent product, and something predictable happens: the sprint reviews multiply, the dependencies between teams become the actual bottleneck, and six months later a senior leader asks, not unreasonably, why the organisation is "doing agile" and still shipping slower than it did before.
This is not evidence that agile does not work at scale. It is evidence that single-team agile practice and multi-team agile practice are different disciplines, and treating the second as a bigger version of the first is the single most common reason scaled agile transformations underdeliver.
Why Single-Team Practices Break Down
A single team's sprint planning works because the team controls its own dependencies — mostly. At enterprise scale, the majority of what blocks a team is work owned by a different team: an API that another team needs to build first, a shared platform capability, a design decision that needs cross-team alignment. No amount of individual-team sprint discipline resolves a cross-team dependency. It requires a coordination mechanism that operates above the level of any single team's backlog.
This is the actual problem scaled agile frameworks exist to solve — not "how do we make fifty teams do standups," but "how do we synchronise fifty backlogs against a shared set of dependencies and a shared strategic direction without recreating the command-and-control planning cycles agile was meant to replace."
The Three Dominant Scaling Frameworks
SAFe (Scaled Agile Framework). The most widely adopted enterprise scaling framework, organising teams into Agile Release Trains (ARTs) of roughly 50–125 people that plan and deliver together on a shared cadence, synchronised through a quarterly Programme Increment (PI) Planning event. SAFe provides the most prescriptive structure of the three — defined roles (Release Train Engineer, Product Manager, System Architect), defined cadences, and defined artefacts. This prescriptiveness is simultaneously its greatest strength (organisations get a complete operating model, not just principles) and its most common criticism (it can become process-heavy and ceremony-driven if adopted mechanically).
LeSS (Large-Scale Scrum). Takes the opposite philosophy — scale Scrum by adding as little as possible to it. LeSS keeps a single Product Backlog and a single Product Owner across all teams, relying on shared sprint reviews and cross-team coordination mechanisms rather than an additional management layer. LeSS demands more organisational discipline and cultural maturity than SAFe because it provides less structural scaffolding — it works best in organisations that already have strong agile practice at the team level and want to preserve Scrum's minimalism rather than add a framework layer on top of it.
Scrum@Scale. Developed by Jeff Sutherland, one of Scrum's original co-creators, Scrum@Scale extends Scrum through a network of interconnected Scrum teams coordinated via a "Scrum of Scrums," with a parallel Executive Action Team addressing organisational impediments that individual teams cannot resolve themselves. It positions itself as more modular and less prescriptive than SAFe while providing more structure than LeSS — a middle path that appeals to organisations wanting scaling guidance without SAFe's full operating model.
Programme Increment Planning — The Mechanism That Actually Does the Work
Whichever framework an organisation adopts, the practice that does the most real synchronisation work is some variant of PI Planning (SAFe's term; LeSS and Scrum@Scale have equivalent big-room planning mechanisms) — a recurring event, typically quarterly, where every team on a shared value stream plans together in the same room (physical or virtual), surfaces cross-team dependencies explicitly, and commits to a shared set of objectives for the coming increment.
The value of PI Planning is not the plan it produces — the plan will be wrong within weeks, as all plans are. The value is that it forces dependencies to surface and be negotiated between teams directly, rather than discovered mid-increment when it is far more expensive to resolve. Organisations that skip or hollow out this event — running it as a status update rather than genuine cross-team negotiation — lose the primary mechanism that makes scaling work at all.
The Failure Modes That Repeat Across Enterprises
Ceremony without operating model change. The most common failure: teams adopt SAFe's ceremonies — PI Planning, ART syncs, Inspect & Adapt — without changing the underlying organisational structure, funding model, or decision rights. The result is agile theatre laid over a fundamentally unchanged command-and-control operating model, which produces more meetings without producing more throughput.
Funding models that contradict the framework. Scaled agile assumes teams are funded to deliver ongoing value against a roadmap, not funded project-by-project against a fixed scope and deadline. Organisations that scale agile ceremonies while retaining annual project-based budgeting create a structural conflict that no amount of framework fidelity resolves — the funding model and the delivery model are optimising for different things.
Coaches without authority to change structure. Agile coaches are frequently tasked with making scaled agile work while having no authority over team boundaries, reporting lines, or funding — the actual levers that determine whether scaling succeeds. Coaching effort applied without structural authority produces marginal improvement at best.
Treating the framework as the destination. SAFe, LeSS, and Scrum@Scale are operating models for achieving fast, coordinated delivery — not the goal itself. Organisations that measure success by "framework adoption fidelity" rather than by DORA metrics and business outcomes optimise for the wrong thing.
What Organisations That Succeed Do Differently
They organise teams around value streams and products, not around technology layers or organisational departments — so that most dependencies are contained within a team rather than requiring cross-team coordination in the first place. They fund persistent product teams rather than temporary projects. They give Release Train Engineers, Scrum of Scrums facilitators, or equivalent coordination roles genuine authority to resolve structural impediments, not just facilitate meetings. And they treat the scaling framework as a starting operating model to be adapted to organisational reality, not a certification to be implemented exactly as documented.
What to Do Next
Three questions that reveal scaled agile maturity in any organisation:
1. When a cross-team dependency is discovered, is there a defined mechanism to resolve it in days, or does it default to escalation and wait? The existence and speed of this mechanism is a better predictor of scaling success than which framework is on the wall.
2. Are teams funded and structured around persistent products and value streams, or around temporary projects and technology silos? A scaling framework layered on project-based funding is fighting its own foundation.
3. Does your PI Planning (or equivalent) event genuinely surface and resolve cross-team dependencies, or has it become a status-reporting ceremony? If it is the latter, the organisation has adopted the artefact without the substance.
The next post in this category covers API Strategy & Integration Architecture — the connective tissue that determines how well all these coordinated teams' systems actually work together.
