Scaling Agile

Scrum is designed for one team: the Scrum Guide describes a Scrum Team of typically 10 or fewer people. Kestrel Energy's Portal team (Product Owner Isabel Santos, Scrum Master Lars de Boer and five Developers) fits that well. But suppose Kestrel decides to rebuild the customer portal, the app and the billing integration at the same time, with five teams. How do five teams work on one product without stepping on each other? That question is what scaling frameworks try to answer.

What scaling has to solve

Adding teams does not add speed in a straight line. Every extra team adds communication paths, and the work of one team starts to depend on the work of another. The problems that any scaling approach has to address are much the same:

• One product, many teams. Customers see one portal, not five team outputs. Someone has to decide what matters most across all teams, and there should be one ordered list of work, not five competing ones.
• Dependencies. When the app team cannot finish a feature until the billing team changes an interface, both teams wait. Dependencies are the main source of delay at scale.
• Integration. Five pieces that each work on their own are not a product. If integration happens only at the end (in a "hardening" phase), the risk that should have been visible every Sprint stays hidden for months.
• Shared standards. One Definition of Done, shared tooling, a common build pipeline (see What Is CI/CD?) and agreements on architecture, so that the work of one team does not quietly break another's.
• Alignment with the organization. Budgets, governance, stakeholders and other departments need to connect to the teams' rhythm without forcing them back into long fixed plans.

First, try not to scale

Many experienced practitioners give the same advice before any framework: the cheapest scaling is the scaling you avoid. Before adding a layer of coordination, ask whether the need for it can be reduced.

• Fewer dependencies. Organize teams around customer-facing features ("feature teams") instead of technical layers ("component teams": a front-end team, a database team, an API team). A feature team can finish a feature on its own; a component team almost never can.
• Better architecture. Clear interfaces between parts of the system, automated tests and continuous integration let teams change their part without coordinating every change. Team structure and system structure tend to mirror each other, so changing one often requires changing the other.
• Smaller product scope. Sometimes "we need five teams" really means "we are trying to do too much at once". Doing fewer things, in order of value, may need only two teams.
• Separate products. If two parts of the work have different customers and goals, they may be two products with two Product Owners, which need no scaling framework at all.

The shape of a team of teams

The frameworks below differ a lot in size and vocabulary, but most of them have the same layers: one product direction at the top, something that coordinates and integrates in the middle, several teams doing the work, and one combined result at the bottom.

Nexus

Nexus is Scrum.org's framework for scaling Scrum. The current Nexus Guide, "The Definitive Guide to Scaling Scrum with Nexus", is dated January 2021. It describes a Nexus as a group of approximately three to nine Scrum Teams that work together to deliver a single product. Nexus deliberately adds as little as possible to Scrum: there is still one Product Owner and one Product Backlog, and the teams work in the same Sprint.

The Nexus Integration Team

The main addition is the Nexus Integration Team: the Product Owner, a Scrum Master and other members (often also members of the teams) who are accountable for making sure the teams produce one integrated, done Increment. They do not do all the integration work themselves; they find and remove integration problems and dependencies, coach the teams, and make sure integration happens continuously rather than at the end.

Nexus events and artifacts

Nexus wraps the Scrum events in a cross-team version of each:

• Cross-Team Refinement: refining Product Backlog items together to spot dependencies and decide which team takes what.
• Nexus Sprint Planning: setting a Nexus Sprint Goal and coordinating the teams' plans; each team then does its own Sprint Planning.
• Nexus Daily Scrum: representatives of the teams inspect integration issues and new dependencies; each team still holds its own Daily Scrum.
• Nexus Sprint Review: one review of the Integrated Increment with stakeholders, replacing the individual team reviews.
• Nexus Sprint Retrospective: improving how the teams work together, alongside each team's own retrospective.

The artifacts follow the same logic: the Product Backlog, a Nexus Sprint Backlog (with the Nexus Sprint Goal as its commitment) and the Integrated Increment (with the Definition of Done as its commitment). The single-team versions are explained on Scrum Artifacts and Commitments.

LeSS

LeSS (Large-Scale Scrum) was created by Craig Larman and Bas Vodde. Its philosophy is "more with less": scale Scrum by removing organizational complexity, not by adding roles and processes. The LeSS site describes two configurations:

• LeSS: up to eight teams of up to eight people each. One Product Owner, one Product Backlog, one Definition of Done and one Sprint shared by all teams. Teams are feature teams and coordinate mostly by talking to each other directly.
• LeSS Huge: up to a few thousand people on one product. According to less.works, the product is divided into Requirement Areas of roughly four to eight teams, each with an Area Product Owner, while there is still one overall Product Owner and one Product Backlog.

LeSS asks a lot of the organization: fewer managers, no separate project or component structures, and a single product view. That is its strength and the reason many organizations find it hard to adopt.

SAFe

SAFe (Scaled Agile Framework), from the company Scaled Agile, is the most widely marketed scaling framework and by far the largest. SAFe 6.0, released in 2023, is still the current numbered version. Since June 2026 the framework site is split into "Core SAFe" (the existing operating model) and "AI-Native SAFe", an addition aimed at AI-augmented teams that sits alongside Core SAFe rather than replacing it.

The Agile Release Train

The basic building block is the Agile Release Train (ART): a long-lived team of agile teams, together with roles such as a Release Train Engineer (a coach for the train) and Product Management, that plans, builds and delivers together on a shared cadence. Teams on a train may use Scrum or Kanban.

The train plans in fixed periods called PIs, usually several Sprints (SAFe says iterations) long; the term originally meant Program Increment and was renamed Planning Interval in SAFe 6.0. Each PI starts with PI Planning: a large planning event, often over two days, where all teams of the train plan together, make dependencies visible and agree on PI objectives. Above the train, SAFe has further levels for large solutions and for portfolio management. Across all levels it prioritizes with Weighted Shortest Job First (see Product Backlog Management).

Criticism and fair use

SAFe is popular with large organizations because it gives them a complete, documented model, a shared vocabulary, training paths and a way to connect agile teams to budgets and governance. Its critics, including well-known agile practitioners, argue that:

• it is heavy and prescriptive, with many roles, events and artifacts, which works against the idea of teams improving their own way of working;
• PI Planning can turn into a fixed plan for months, so teams respond to change less than the framework intends;
• it is easy to adopt the vocabulary while keeping the old hierarchy and project structures underneath.

Supporters answer that SAFe is meant to be configured, not adopted whole, and that a large organization needs some structure to start from. Both sides agree on one thing: the result depends more on how seriously an organization changes than on the framework's name.

Scrum@Scale

Scrum@Scale was created by Jeff Sutherland, co-creator of Scrum, and is published by Scrum Inc. Its guide (version 2.1, February 2022, is the latest we know of) scales by linking teams into networks:

• A Scrum of Scrums is a team made up of representatives of several Scrum Teams who meet to remove impediments and coordinate delivery. Scrums of Scrums can in turn form larger groups.
• The Scrum Master cycle (the "how") ends in an Executive Action Team, which removes organizational impediments.
• The Product Owner cycle (the "what") links Product Owners through a Chief Product Owner up to an Executive MetaScrum, which sets priorities for the whole organization.

The "Spotify model"

The Spotify model is the popular name for the team structure described by Henrik Kniberg and Anders Ivarsson in a 2012 paper, "Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds":

• Squads: small, autonomous, cross-functional teams, each owning part of the product;
• Tribes: groups of squads working in a related area;
• Chapters: people with the same skill (for example all testers) across squads in a tribe, usually with a line manager from that chapter;
• Guilds: informal communities of interest across the whole company.

The paper described one company at one moment, not a framework. As reported in later interviews and articles, people who worked at Spotify have said they never invented the expression "Spotify model" and that even when the paper was written, it described an aspiration more than daily reality. Organizations that copied the names (renaming departments to tribes and teams to squads) without Spotify's culture of trust and autonomy usually got the labels without the results. The useful lesson is the original one: design your structure around autonomy and alignment, and keep changing it.

Comparing the approaches

Which one fits depends on the situation described on Choosing an Approach: a few teams on one product are well served by Nexus or LeSS; a large organization with many products, regulators and fixed budget cycles often looks at SAFe; and many organizations combine ideas from several. Common traps for each are on Agile Tools and Anti-Patterns.