Scrum was designed for one team of around ten people. Many products require dozens or hundreds of people. Scaling frameworks try to keep Agile values intact while coordinating across teams.
When You Actually Need Scaling
Before adopting a framework, check the problem. Multiple teams introduce coordination cost — splitting work, integrating, dependencies. Sometimes the right answer is to not scale: keep one team, or split the product so each team owns a real slice end-to-end.
You probably need scaling structure when:
- 5+ teams contribute to one product or platform.
- Cross-team dependencies show up in every Sprint.
- Stakeholders need a predictable forecast across teams.
- Architecture must align across many independent decisions.
SAFe — Scaled Agile Framework
The most widely adopted, most prescriptive scaling framework. Created by Dean Leffingwell. Levels: Team, Program, Large Solution, Portfolio.
Key concepts
- Agile Release Train (ART). 5–12 teams, 50–125 people, working on one product.
- Program Increment (PI). 8–12 weeks of aligned work; the unit of planning above the Sprint.
- PI Planning. 2-day event where the entire ART plans the next PI together.
- Roles: RTE (Release Train Engineer), Product Manager, System Architect, Business Owners — on top of standard Scrum roles.
- Inspect & Adapt. ART-level retrospective at end of PI.
Strengths
- Battle-tested at large enterprises (banks, telecoms, defence).
- Provides explicit answers for hard questions like cross-team dependencies, architecture, portfolio prioritisation.
- Strong training and certification ecosystem.
Weaknesses
- Heavy. PI Planning alone is 2 days of 100+ people; significant cost.
- Easy to adopt the rituals without the mindset.
- Critics argue it is "Waterfall in Agile clothing" — fixed PIs feel quarterly.
- Often mandated top-down rather than evolved.
LeSS — Large Scale Scrum
Created by Craig Larman and Bas Vodde. Goal: keep Scrum almost identical at scale, just with multiple teams sharing one Product Backlog and one Product Owner.
Key concepts
- Up to 8 teams, one Product Owner, one Product Backlog, one shared Sprint cadence.
- One Sprint Review and one Retrospective for the whole product (often with team-level mini-retros first).
- Components and architecture emerge from cross-team work; minimal added roles.
- "LeSS Huge" extends to many requirement areas with area Product Owners.
Strengths
- Stays close to Scrum; little new vocabulary.
- Pushes responsibility down to teams, encouraging real cross-functionality.
- Avoids the "scaled frameworks add roles" trap.
Weaknesses
- Requires deep organisational change — single backlog and PO across many teams is a hard sell.
- Less prescriptive guidance for portfolio-level concerns.
- Adoption is harder to "buy" as a programme; usually has to grow organically.
Nexus
From Ken Schwaber and Scrum.org. Lighter extension of Scrum for 3–9 teams.
- Adds a Nexus Integration Team responsible for ensuring an integrated Increment each Sprint.
- New events: Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective.
- One Product Backlog, one Product Owner; teams pull from it.
Sweet spot: organisations that are happy with Scrum and need a small step up in coordination without SAFe weight.
Scrum@Scale
From Jeff Sutherland (Scrum co-creator). Two parallel networks:
- Scrum of Scrums network for delivery (how to build).
- MetaScrum network for product (what to build).
Designed to be modular — adopt only the pieces you need.
Spotify Model
Squads, Tribes, Chapters, Guilds. Famously described in 2012; equally famously, Spotify themselves later said they had moved on. It is a culture pattern, not a framework: empowered cross-functional squads with light coordination.
Many organisations have adopted the labels. Few have adopted the autonomy that makes the labels meaningful.
Common Scaling Concerns
| Concern | What scaling frameworks try to solve |
|---|---|
| Cross-team dependencies | Joint planning events, shared backlog, integration teams |
| Architecture alignment | System architect roles, communities of practice |
| Portfolio prioritisation | Portfolio backlog, lean budgeting, business epics |
| Predictability for stakeholders | PIs, integrated demos, big-room planning |
| Specialised skills (DevOps, security) | Shared services teams, embedded specialists |
Choosing
| Situation | Likely fit |
|---|---|
| 3–9 teams, mature Scrum | Nexus or Scrum@Scale |
| Up to 8 teams, real organisational appetite for change | LeSS |
| Large enterprise, regulated, top-down adoption | SAFe |
| Platform with autonomous squads | Spotify-inspired culture |
| Pure ops / support | Kanban at scale (Enterprise Services Planning) |
Scaling Anti-Patterns
- Scale before competent. If a single team is not yet running Scrum well, scaling will not fix it.
- Cargo-cult adoption. "We did SAFe training; here are our new ceremonies." No measurable improvement.
- Scaling frameworks as rebadged PMO. Same control structure, new vocabulary.
- Forgetting Conway's Law. If your architecture is monolithic, no scaling framework will produce independent teams.
Cert Mapping
| Cert | Scope |
|---|---|
| SAFe Agilist (SA) | Entry SAFe certification |
| SAFe Scrum Master (SSM), SAFe POPM | Role-specific SAFe certifications |
| Certified LeSS Practitioner | LeSS-specific |
| Scaled Professional Scrum (SPS) | Nexus-based, from Scrum.org |
| PMI-ACP | Mentions multiple scaling models |
The final lesson covers the metrics that tell you whether any of this is actually working.