The Software Wiki

Scaling agile

Properties3
descriptionFrameworks for running agile across many teams working on one product, from minimal (LeSS, Nexus) to prescriptive and heavyweight (SAFe).
tagsprocess, methodology
aliasesAgile at scale, Scaling frameworks, Scaled agile, SAFe, Scaled Agile Framework, LeSS, Large-Scale Scrum, Nexus, Scrum@Scale, Spotify model

4 min read

Scaling agile

By Allen Jay Bercero

Scaling agile is applying agile when many teams work on one product: the situation single-team frameworks like Scrum were never designed for. One team with one Product backlog is straightforward; twenty teams that must ship a coherent product together is a coordination problem, and several frameworks exist to tackle it. There is no single standard, and the options range from barely-more-than-Scrum to large, prescriptive systems.

Also known as

agile at scale · scaled agile · scaling frameworks

Don't confuse with

  • Scaling agile (many teams, one product, coordinating to ship together) vs “doing agile in a big company” (lots of separate teams that each run Scrum independently). Scaling is about the dependencies between teams on a shared product, not headcount.
  • The frameworks are not interchangeable, and none is official. Unlike Scrum (one Scrum Guide), scaling has competing frameworks with different philosophies. Picking one is a real decision.

Why scaling is hard

Add teams to one product and new problems appear that a single team never has:

  • Dependencies: team A’s work blocks team B’s; someone has to sequence them.
  • Integration: many streams of code must combine into one working, releasable product.
  • One product, many backlogs? Do you keep a single Product backlog and one Product Owner, or split them (and risk the teams drifting apart)?
  • Alignment: keeping dozens of teams pointed at the same goals without a heavy command structure.

The frameworks below are different answers to those questions.

The main frameworks

  • SAFe (Scaled Agile Framework): the most widely adopted and the most prescriptive. Created by Dean Leffingwell. It organizes work into configuration levels (Team, Program, Large Solution, Portfolio), groups teams into an Agile Release Train (ART), and synchronizes them with big PI Planning events (PI = Planning Interval, called Program Increment through SAFe 4.x). Powerful for large enterprises; often criticized as heavy, top-down, and “not really agile.”
  • LeSS (Large-Scale Scrum): the minimalist end. Created by Craig Larman and Bas Vodde. It scales Scrum by adding as little as possible: one Product Owner, one Product Backlog, and one shared Sprint across multiple teams. The philosophy is “more with less”: keep Scrum, don’t bolt on layers.
  • Nexus: a lightweight framework from Ken Schwaber / Scrum.org, building on Scrum for a handful of teams (roughly 3–9). It adds a Nexus Integration Team to handle cross-team integration, and little else.
  • Scrum@Scale: from Jeff Sutherland (a Scrum co-creator). Scales Scrum fractally through a “scrum of scrums,” aiming to keep the scaled structure as lightweight as the single-team one.

The Spotify “model”

You’ll hear about squads, tribes, chapters, and guilds: the “Spotify model,” from a 2012 write-up by Henrik Kniberg and Anders Ivarsson.

It was never a framework

The write-up was a snapshot of what Spotify was trying at one moment, not a ready-made system to copy. Spotify itself has said it didn’t fully work and was never “the way Spotify works.” Teams that adopt “the Spotify model” as a blueprint are usually cargo-culting a poster. Useful as ideas (autonomy, community-of-practice groups), not as a framework to install.

Choosing one

Think of a spectrum from minimal to heavyweight:

LeSS / Nexus (keep Scrum, add almost nothing) → Scrum@Scale → SAFe (a full enterprise system)

  • Fewer teams and a strong agile culture lean toward LeSS or Nexus.
  • Large enterprises with heavy governance, budgets, and many stakeholders often land on SAFe, accepting more process for more coordination.

The common failure mode is picking a heavy framework to look organized while losing the agility that was the point. More structure is a cost, not a virtue; buy only as much as the dependencies actually require.

In plain English

One Scrum team is easy. Fifty teams building one product need a way to stop tripping over each other. These frameworks are the competing rulebooks for that, from “barely more than Scrum” (LeSS, Nexus) to “a whole enterprise operating system” (SAFe).

See also

References

Graph View

Recent Notes

Backlinks