Scaling Frameworks

## The problem all four are solving Every scaling framework answers the same question: how do several teams produce one product without either colliding or drifting apart. They agree on four things — one product, one ordering of the work for it, one shared standard for what "finished" means, and a regular point at which everything is assembled and inspected together. What differs is **how much machinery each prescribes** to protect those four, and therefore how much prescription the organisation must be willing to absorb. A useful way to hold them is on a single axis, from lightest to heaviest. ## Nexus — a thin integration layer Nexus takes three to nine teams working from one product backlog and adds the minimum needed to keep them integrated. Its distinctive piece is the **Nexus Integration Team**, an accountability usually staffed from the delivery teams, for making sure one assembled, working version of the whole product exists at the end of every iteration — not nine separately declared finished pieces. Around it sit cross-team versions of the familiar events: a joint planning session where representatives surface dependencies before each team plans in detail, a short daily meeting for those representatives, a joint inspection of the assembled result with stakeholders, and a joint retrospective. What it optimises for: **getting one working whole out of a small number of teams**, with almost no new structure. What it does not do: help you align funding, roadmaps or dozens of teams. ## LeSS — remove the coordination rather than add it LeSS starts from an unusual premise: most coordination exists because the organisation created the need for it. So instead of adding layers it **removes the reasons to coordinate**. One product owner orders one product backlog for the whole product. Every team shares one iteration, one shared standard for finished work, and one inspection with stakeholders. Teams are broad enough to take a customer-facing item end to end through whatever code it touches, so a typical item needs one team rather than four. Planning happens in two parts: a shared part where teams pick up items and surface what they need from each other, and a per-team part. Beyond roughly eight teams, its larger variant splits the product into **requirement areas**, each with its own area owner and its own slice of the product backlog, so that one person is never ordering work for forty teams. What it optimises for: **a permanently low dependency load**. What it costs: real organisational change — broader teams, shared code ownership, fewer specialists guarding a single layer. ## Scrum@Scale — scale by composition Scrum@Scale takes the position that the team-level framework already works and should simply be repeated. Teams form a **Scrum of Scrums**, which behaves like a team of teams and can itself be composed into a larger one, so growth adds another instance of the same pattern rather than a new kind of layer. It separates two linked cycles: one governing **what gets built** — product ordering across the network, with a chief product owner and a forum where stakeholders agree priorities — and one governing **how the work gets done** — impediments, practices and improvement, with an executive group accountable for removing organisational blockers. What it optimises for: **growing without inventing a management layer**. What it costs: it is a pattern rather than a recipe, so it gives less help to an organisation that wants to be told exactly what to do. ## SAFe — prescription and a planning cadence SAFe is the heaviest and most detailed. Its two signature pieces are the **Agile Release Train** — a long-lived grouping of teams, commonly described as roughly 50 to 125 people, that plan, integrate and release together on a shared cadence — and **PI planning**, a big-room event at which the whole train plans the next planning interval of several iterations together, in one place, producing a visible map of cross-team dependencies and a set of agreed objectives. Above the train sit further defined levels for very large solutions and for portfolio funding, each with named roles and artifacts. What it optimises for: **alignment and predictability across a large programme**, including groups outside engineering. What it costs: adaptability, and a substantial share of everyone's time. ## Choosing between them | Framework | Typical span | Signature mechanism | Optimises for | |---|---|---|---| | Nexus | 3–9 teams | Integration accountability plus cross-team events | One assembled product each iteration | | LeSS | up to ~8 teams; larger variant beyond | One owner, one backlog, end-to-end teams | Fewer dependencies to coordinate | | Scrum@Scale | Any size, by composition | A network of Scrums; separate what and how cycles | Growth without a new layer | | SAFe | ~5–12 teams per train, many trains | Long-lived train plus big-room planning cadence | Alignment across a programme | Two things interviewers listen for: - **Heaviness is not maturity.** Choosing the most prescriptive framework says something about the organisation's constraints — external commitments, funding cycles, how much guidance it needs — not about how good its engineers are. - **None of them replaces team-level practice.** Every one assumes teams that can already finish work inside an iteration. Layered over teams that cannot, all four produce the same result: coordinated failure, on a cadence.