Scaling Agile

Before we discuss how to scale, we need to address whether you should. In my experience, at least half the organizations adopting scaling frameworks do not need them. They have 3-4 teams building loosely coupled services, and the coordination overhead of a formal scaling framework exceeds the coordination problems it solves.

The honest test: if your teams can ship independently more than 70% of the time without coordinating with other teams, you do not need a scaling framework. You need better architecture (decoupled services, well-defined APIs) and lightweight coordination (a weekly cross-team sync, a shared dependency board).

Scaling frameworks solve a specific problem: when multiple teams must coordinate frequently to deliver value. If you are forcing that coordination because of a monolithic codebase or shared database, fix the architecture first. Adding process on top of bad architecture is like putting a racing harness on a horse with a broken leg.

I have seen organizations spend 12-18 months and millions of dollars implementing SAFe when the actual problem was a monolithic deployment pipeline. After the SAFe rollout, they still had the same bottleneck. They just had more meetings around it.

The Scaled Agile Framework is the most widely adopted scaling framework, and also the most controversial. It has been called everything from “the answer to enterprise agility” to “Shitty Agile for Enterprises.” The truth, as usual, is more nuanced.

When SAFe Actually Works

SAFe works in organizations with these characteristics: 10+ teams that must coordinate on shared deliverables, strong executive sponsorship with patience for a 12-18 month transformation, an existing waterfall culture that needs structured guardrails during the transition, and regulatory or compliance requirements that demand documented processes.

In these environments, SAFe provides something valuable: a pre-packaged operating model that leadership can understand. The PI (Program Increment) planning event gives executives visibility into what teams are building and why. The ART (Agile Release Train) provides a stable team-of-teams structure. The ceremony cadence creates predictable touchpoints.

I have seen SAFe work well in large financial institutions where 15-20 teams needed to coordinate on quarterly regulatory releases. The PI planning event became the heartbeat of the organization, replacing dozens of ad-hoc coordination meetings. Teams could see their dependencies, negotiate scope trade-offs, and commit to a shared plan.

When SAFe Becomes Theater

SAFe fails when organizations adopt the ceremonies without the mindset. The warning signs:

• PI planning becomes a 2-day estimation exercise where teams are told what to commit to rather than negotiating scope
• The “innovation and planning” sprint gets consumed by spillover work from the previous PI instead of actual innovation
• Release Train Engineers become project managers with a new title, tracking tasks rather than enabling flow
• Teams lose autonomy because every decision must be escalated to the ART level
• The framework is implemented “by the book” with no adaptation to the organization's actual context

The most common failure mode: an organization hires SAFe consultants, trains 200 people, conducts a PI planning event, and declares themselves “agile at scale.” Six months later, the same dysfunction exists but now it has Agile vocabulary. This is what critics rightly call “Agile cosplay.”

Large-Scale Scrum (LeSS) takes the opposite philosophy to SAFe. Where SAFe adds structure, LeSS removes it. The core principle: scaling is about descaling the organization, not adding more process.

LeSS works with up to 8 teams sharing a single product backlog and a single Product Owner. There is one sprint, one sprint review, and one overall retrospective. Teams coordinate through shared design workshops, cross-team refinement sessions, and communities of practice rather than formal coordination roles.

The appeal of LeSS is its honesty about organizational design. It forces you to confront hard questions: Why do you need 8 teams? Can you restructure into feature teams that can deliver end-to-end? Can you simplify the product so fewer teams are needed?

The challenge is that LeSS requires significant organizational change. It demands feature teams (not component teams), eliminates most middle management coordination roles, and requires a genuinely empowered Product Owner. In my experience, LeSS works beautifully in product companies with strong engineering cultures, and struggles in traditional enterprises where organizational structure is political.

If you are choosing between SAFe and LeSS, here is my heuristic: if your organization values predictability and structure, start with SAFe and evolve toward simplicity. If your organization values autonomy and is willing to restructure teams, start with LeSS.

For most organizations with 3-8 teams, neither SAFe nor LeSS is the right answer. What works is something I call “Aligned Autonomy,” borrowing the concept from Henrik Kniberg's work at Spotify (though, as we will discuss, the Spotify model itself is largely a myth).

The model has four components:

This model works because it provides just enough coordination to prevent teams from stepping on each other without imposing so much process that teams lose their ability to move fast. The key insight: coordination is a cost, not a feature. Minimize it.

We need to address the elephant in the room. The “Spotify Model” (squads, tribes, chapters, guilds) is the most referenced organizational model in Agile, and it is largely a fiction.

The model was described in a 2012 whitepaper by Henrik Kniberg and Anders Ivarsson. What most people miss: the paper described an aspiration, not a reality. Kniberg himself has said repeatedly that Spotify never fully implemented the model as described. By the time the paper became famous, Spotify had already moved on to different approaches.

Former Spotify engineers have written about the reality: the matrix structure created confusion about reporting lines, chapters were inconsistently implemented, guilds were mostly inactive, and the model worked primarily because of Spotify's engineering culture, not because of the organizational structure.

The lesson: do not copy organizational structures from other companies. The model that works for a 2,000-person Swedish music streaming company will not work for your 200-person fintech. Instead, identify your specific coordination problems and design lightweight solutions for those problems. If your biggest issue is shared code ownership, create communities of practice. If it is cross-team dependencies, create a dependency board. If it is architectural alignment, create an architecture guild. You do not need to buy the whole framework.

Whether you call it PI planning, quarterly planning, or “big room planning,” the concept is the same: get teams together to align on what they are building and why. Done well, this is the single most valuable event in a scaled environment. Done poorly, it is 2 days of death by PowerPoint.

The One-Day Format That Works

The critical success factor: leadership must come to this event willing to negotiate scope. If the plan is dictated top-down and teams are just assigning dates, you are doing waterfall planning with sticky notes. The entire point is the conversation between teams and between teams and leadership about what is feasible and what trade-offs need to be made.

Dependencies are the silent killer of multi-team delivery. A study by QSM Associates found that cross-team dependencies add an average of 40% to delivery timelines. The goal is not to manage dependencies better. The goal is to eliminate them. But until your architecture supports full team autonomy, you need a practical system.

I use a simple three-tier classification:

• Hard dependencies: Team A cannot start their work until Team B delivers something. These are the dangerous ones. Minimize by architectural decoupling (API contracts, mocks, contract testing).
• Soft dependencies:Team A's work is better/easier if Team B delivers first, but they can work around it. Manage through sequencing and communication.
• Knowledge dependencies: Team A needs information or expertise from Team B. Solve with documentation, pairing sessions, or temporary team embeddings.

For each hard dependency, insist on three things: an explicit contract (API spec, interface definition), a delivery date with a buffer, and a fallback plan if the dependency is not met on time. The fallback plan is non-negotiable. In my experience, roughly 30% of cross-team dependencies miss their target date. If you do not have a Plan B, a single missed dependency can cascade across your entire program.