Scaling Agile: SAFe, Scrum of Scrums, LeSS, and the Spotify Model
Scrum was designed for one small team — here's what happens once a product needs a dozen of them.
Advanced
TopNotchNote
Notes that matter
why scaling is a different problem
Scrum was designed around a single small team, typically ten people or fewer. Once a product needs many teams working against the same codebase or product, new problems appear that a single team's framework was never built to solve: dependencies between teams, shared architecture decisions, keeping release cadence coordinated, and avoiding two teams quietly building the same thing.
scrum of scrums: the lightest touch
Scrum of Scrums is the minimal-structure approach: each team's own Scrum stays essentially unchanged, but a representative from each team meets regularly in a "Scrum of Scrums" specifically to surface and resolve cross-team dependencies and blockers. It adds almost no new roles or ceremonies, which makes it a reasonable first step for a handful of related teams — and a poor fit once the number of teams grows large enough that a single coordination meeting can't cover it all.
less (large-scale scrum): scale by simplifying
LeSS takes a deliberately minimalist approach: keep Scrum's rules essentially intact and apply them across multiple teams working from one shared product backlog with one Product Owner, instead of inventing new layers of roles and process. Its explicit philosophy is "more with less" — resisting the instinct to add structure as an organization scales, and instead scaling by simplifying and removing.
safe (scaled agile framework): the comprehensive option
SAFe is the most comprehensive and prescriptive of the major scaling frameworks. It adds structured layers above the team level — a "Program" layer that coordinates multiple teams' release cadence through a structured PI (Program Increment) Planning event, and a portfolio layer for higher-level strategy and investment decisions. SAFe is widely adopted, especially in large enterprises that want a well-documented, comprehensive system to adopt wholesale — but it's also frequently criticized for the sheer volume of added roles, ceremonies, and artifacts, which some argue sits uneasily against Agile's original preference for individuals and interactions over heavy process.
the spotify model: an org-design pattern, not a framework
The Spotify model isn't a formal framework in the same sense as the others — it describes an organizational structure, not a process, and Spotify itself has said other companies shouldn't copy it as a rigid template. The pattern: squads (small, autonomous, cross-functional teams, similar in spirit to a Scrum team), tribes (collections of related squads), chapters (people with the same specialty across squads — e.g. all backend engineers — for skill-sharing and consistency), and guilds (informal, voluntary communities of interest across the whole organization). It's mainly influential as inspiration for team autonomy in org design, not as a prescriptive ceremony structure to install.
how to choose
| Situation | Reasonable starting point |
|---|---|
| A handful of related teams, light coordination needed | Scrum of Scrums |
| Committed to staying close to standard Scrum, resisting extra process | LeSS |
| Large enterprise wanting a comprehensive, documented system | SAFe |
| Mainly focused on org design and team autonomy, not ceremonies | Spotify-style squads/tribes (adapted, not copied) |
a short example
A company grows from one Scrum team to four teams building the same consumer product. It starts light, with a Scrum of Scrums meeting as cross-team dependencies begin appearing. Six months later, coordination overhead has grown past what an informal weekly sync can track, and leadership evaluates SAFe against LeSS. They choose LeSS specifically because the organization values staying close to standard Scrum and wants to avoid adopting a large new layer of roles and ceremonies — a different company facing the same growth, but wanting a fully documented, off-the-shelf system for a much larger org, might reasonably choose SAFe instead.
practical notes
Scaling frameworks solve coordination problems that don't exist yet for a single team. Adopting one before it's actually needed just adds process overhead with no coordination problem to justify it.
The goal at every scale is still Agile's underlying values. Any scaling approach that piles on so much process it stops serving those values has defeated its own purpose, regardless of which named framework it borrows from.