You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
Scrum and Kanban work well for a single team building a single product. But what happens when the product is too large for one team, or when multiple teams need to coordinate? Scaling Agile frameworks address this challenge by providing structures, roles, and practices for multi-team Agile delivery.
Large products and organisations face challenges that a single Scrum team does not:
| Challenge | Description |
|---|---|
| Dependencies | Multiple teams working on the same product create technical and functional dependencies |
| Coordination | Teams need to align on architecture, integration, and release plans |
| Consistency | Shared standards (Definition of Done, coding standards) must be maintained across teams |
| Backlog management | A single Product Backlog may serve multiple teams, requiring sophisticated prioritisation |
| Stakeholder complexity | More teams means more stakeholders with competing priorities |
| Framework | Creator(s) | Scale | Approach |
|---|---|---|---|
| SAFe (Scaled Agile Framework) | Dean Leffingwell | Enterprise-wide (50-10,000+ people) | Comprehensive, prescriptive framework with multiple configurations |
| LeSS (Large-Scale Scrum) | Craig Larman & Bas Vodde | 2-8 teams (LeSS) or 8+ teams (LeSS Huge) | Minimalist; extends Scrum with minimal additions |
| Nexus | Ken Schwaber (Scrum.org) | 3-9 Scrum teams | Lightweight; adds a Nexus Integration Team and events |
| Scrum@Scale | Jeff Sutherland | Any size | Modular; networks of Scrum teams with Scrum of Scrums |
| Spotify Model | Spotify (Henrik Kniberg) | Medium to large engineering orgs | Cultural model with Squads, Tribes, Chapters, and Guilds |
| Disciplined Agile (DA) | Scott Ambler & Mark Lines | Enterprise-wide | Toolkit approach; provides decision frameworks rather than prescriptions |
SAFe is the most widely adopted scaling framework, used by a majority of enterprises that scale Agile. It is comprehensive and prescriptive, providing detailed guidance for every aspect of Agile at scale.
| Configuration | Description | Scope |
|---|---|---|
| Essential SAFe | The basic building block: Agile Teams + Agile Release Train (ART) | Single program (50-125 people) |
| Large Solution SAFe | Adds Solution Trains for very large systems | Multiple ARTs |
| Portfolio SAFe | Adds Lean Portfolio Management for strategy and funding alignment | Enterprise-level |
| Full SAFe | Combines all three configurations | Largest enterprises |
| Concept | Description |
|---|---|
| Agile Release Train (ART) | A long-lived team of Agile teams (typically 50-125 people) that incrementally develops and delivers solutions |
| Program Increment (PI) | A time-boxed planning interval (typically 8-12 weeks, containing 4-6 Sprints) |
| PI Planning | A two-day face-to-face event where all ART members plan the next PI together |
| Release Train Engineer (RTE) | Servant-leader and chief Scrum Master for the ART |
| Product Management | Responsible for the Program Backlog and defining features |
| System Demo | End-of-Sprint demo of the integrated system across all teams |
| Pros | Cons |
|---|---|
| Comprehensive guidance for large organisations | Can feel bureaucratic and heavyweight |
| Well-documented with extensive training and certification | Expensive to implement (training, tooling, consulting) |
| Addresses portfolio, program, and team levels | May impose unnecessary structure on mature Agile teams |
| Strong community and industry adoption | Critics argue it is "Waterfall in Agile clothing" |
LeSS takes the opposite approach to SAFe: it extends standard Scrum with minimal additions and focuses on simplicity and descaling (removing unnecessary organisational complexity).
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.