Scaling Agile: SAFe and LeSS

Scrum and Kanban were designed for a single team: 5-9 people, one backlog, one daily standup. As long as there is a single team, everything is simple — it decides for itself what to do and is accountable for the result on its own. But a large product is rarely built by a single team. A banking app, a marketplace, an ERP — these involve dozens, if not hundreds, of developers. And that raises the question: how do you get 10, 20, or 50 teams moving in the same direction without turning everything into chaos? Agile scaling frameworks — SAFe, LeSS, and others — try to answer it. Let's look at where the problem comes from and what these approaches offer.

Why single-team Scrum doesn't scale on its own

When a single team works on a product, all the agreements fit in people's heads. Everyone knows who is doing what; if a task depends on another task, people simply talk it over and sort it out.

Add a second team and dependencies appear. Team A can't finish its feature until team B ships the API it needs. Team B has no idea it has blocked someone, because it has its own backlog and its own priorities. Multiply that by ten teams and you get a situation where nobody sees the big picture, releases slip, and half the time goes into figuring out "have you done this yet or not?"

The three main pains of scaling:

• Cross-team dependencies. One team waits on another; blockers surface at the last moment.
• Shared backlog and priorities. The product has a single list of tasks, but there are many teams — who decides what matters more?
• Synchronization. If teams work at different rhythms and release out of step, it's hard to assemble a coherent product from their pieces.

Scaling frameworks are essentially a set of rules and ceremonies that try to address these three pains. They differ in how many layers they add on top of ordinary Scrum.

SAFe: a heavyweight framework with levels

SAFe (Scaled Agile Framework) is the most popular and the "heaviest" of the approaches. Its idea: since there are many teams, you need separate levels of management, each with its own roles and ceremonies.

There are usually three levels:

Key SAFe concepts:

• Agile Release Train (ART) — the "release train." This is a group of 5-12 teams (50-125 people) that work toward a common goal and release in sync. Everyone rides the same train on the same schedule.
• PI Planning (Program Increment Planning) — a large shared planning event every 8-12 weeks, where all the teams on the train gather (in person or online) and spend two days agreeing on who does what and how to resolve dependencies. This is the heart of SAFe.

SAFe provides structure and predictability, but it pays for that with weight: many roles (Release Train Engineer, Product Manager, System Architect, and others), many ceremonies, many documents. Critics say SAFe risks turning Agile back into a heavyweight management process with a large number of managers. That's why it's more often chosen by large corporations that value control and predictability over flexibility.

LeSS: Scrum as-is, but for many teams

LeSS (Large-Scale Scrum) starts from the opposite principle: don't add layers, but keep Scrum almost untouched and stretch it across several teams.

The main differences from SAFe:

• One shared backlog for the whole product and one Product Owner. They set priorities for all teams at once — there is no separate "program" level with its own task lists.
• One shared sprint for all teams. Everyone starts and finishes at the same time, and shows a single result at a joint review.
• Minimal new roles. LeSS doesn't introduce a pile of positions — the basic Scrum roles remain, they're just applied to several teams.

LeSS works for 2-8 teams (in the LeSS Huge variant — more, with a split into requirement areas). The philosophy here is this: complexity should be removed, not added. If coordination required a lot of new roles and processes, then the problem is being solved in the wrong place. LeSS suits organizations willing to change how teams are structured for the sake of simplicity, rather than growing a management layer.

In short, the difference: SAFe adds levels and roles on top of the teams; LeSS strips away everything unnecessary and makes teams negotiate directly around a single backlog.

The Spotify model: an example, not a framework

Discussions of scaling often bring up the Spotify model with its squads, tribes, chapters, and guilds. It's important to understand: this is not a framework, but an account of how work was organized at one company at a particular moment.

The terms are simple:

• Squad — a small autonomous team, analogous to a Scrum team, responsible for its own slice of the product.
• Tribe — a group of squads working in a related area.
• Chapter — people of one specialty (for example, all backend developers) within a tribe, so they can share practices.
• Guild — a community of interest that spans the whole company (for example, everyone interested in testing).

The model is elegant and many have tried to copy it. But there's a catch: even at Spotify itself, it was a description of the current state, not a ready-made recipe — and within the company this scheme changed over time. Copying someone else's team structure without understanding which problems it solved is a common mistake. The Spotify model is useful as a source of ideas (team autonomy, horizontal communities), but not as a framework you can "roll out" by following instructions.

The core principle: first remove dependencies, then add ceremonies

From all of the above follows the main conclusion, which often gets lost behind framework names.

You don't scale for the sake of scaling. All the SAFe and LeSS ceremonies exist to fight cross-team dependencies. But the cheapest way to deal with a dependency is to remove it, not to learn how to coordinate around it.

What removes dependencies first of all:

• Architecture. If the product is split into loosely coupled parts (services, modules) with clear boundaries, a team can build its slice while barely depending on its neighbors. Good architecture removes more dependencies than any shared planning.
• Autonomous teams. If a team has everything it needs to take a task all the way to the finish on its own — from the database to the interface — it doesn't have to wait on four other teams.

And only when dependencies objectively remain (and you can't remove them entirely in a large product) does it make sense to add coordination — PI Planning, a shared backlog, synchronized sprints. The order is precisely this: first architecture and team boundaries, then ceremonies. Do it the other way around — bolt a heavyweight framework onto a tangled system — and you get an expensive ritual for managing chaos, not a solution to the problem.

That's why the choice of framework is secondary. First ask honestly: why do the teams have to wait on each other so much in the first place? Often the answer lies not in the processes, but in the design of the product and the teams.

In short

• Scrum and Kanban were designed for a single team; with 10+ teams on one product you get dependencies, a struggle over the shared backlog, and the problem of synchronization.
• SAFe — a heavyweight framework with "team / program / portfolio" levels and the concepts of Agile Release Train and PI Planning; many roles and ceremonies, chosen by large corporations for the sake of predictability.
• LeSS — "Scrum as-is" for several teams: one backlog, one Product Owner, one shared sprint, minimal new roles; the philosophy is to remove complexity, not add it.
• The Spotify model (squads / tribes / chapters / guilds) is an example of how work was organized at one company, not a framework; copying its structure blindly is a mistake.
• All scaling ceremonies exist to fight cross-team dependencies.
• The cheapest way to deal with a dependency is to remove it: good architecture and autonomous teams remove more dependencies than any shared planning.
• The right order is: first architecture and team boundaries, then coordination ceremonies — not the other way around.

What to read next

• Scrum
• Kanban
• Development models