Most scaling frameworks add overhead that contradicts the Agile values they claim to extend. The best approach is usually to not need a scaling framework at all — keep teams small, autonomous, and loosely coupled. But when coordination across multiple teams is unavoidable, these are the main options.

SAFe (Scaled Agile Framework)

The most widely adopted framework, and the most criticised.

Structure:

  • Team level — Scrum/Kanban teams of 5–11 people
  • Program level — Agile Release Train (ART) of 50–125 people, coordinated through PI Planning
  • Large Solution level — multiple ARTs forming a Solution Train
  • Portfolio level — Lean portfolio management, strategic themes, value streams

PI Planning — a 2-day event every 8–12 weeks where all teams in an ART plan together face-to-face. Often cited as the most valuable part of SAFe regardless of whether you adopt the rest.

Criticism:

  • Adds layers of process, roles (RTE, Solution Architect, Epic Owner), and ceremonies
  • Can feel like waterfall wrapped in agile terminology
  • Certification-driven adoption often means box-ticking over genuine transformation
  • “SAFe is what enterprises do instead of being agile” — common criticism

When it works: large regulated organisations that need governance and compliance artefacts, and where the alternative is genuine waterfall.

Shape Up

Basecamp’s alternative to Scrum sprints and backlogs.

Core concepts:

  • 6-week cycles — long enough to build something meaningful, short enough to maintain urgency
  • 2-week cooldown — between cycles for bug fixes, exploration, and recovery
  • Shaping — senior people define the problem and a rough solution (the “shaped pitch”) before handing to a team. Not a spec — a bounded concept
  • Pitches — teams bet on shaped pitches. If a pitch isn’t completed in 6 weeks, it’s not automatically continued — it must be re-pitched
  • No backlog — old pitches are discarded. If something is important, it’ll come back
  • No estimation — instead, shape work to fit the appetite (time budget)

Circuit breaker: if work isn’t done in the cycle, it stops. This prevents projects from dragging on indefinitely.

Best for: small-to-medium product companies that want structure without the ceremony of Scrum. Requires strong shaping skills and trust in teams.

LeSS (Large-Scale Scrum)

Craig Larman and Bas Vodde’s approach: scale by reducing complexity, not adding process.

Philosophy: use regular Scrum with minimal additions. One Product Owner, one Product Backlog, one Sprint, multiple teams.

Key differences from SAFe:

  • No new roles (no RTE, no Solution Architect)
  • No additional ceremonies beyond Scrum’s
  • Teams coordinate directly, not through intermediaries
  • Emphasises organisational de-scaling (flatten hierarchy, reduce management layers)

Best for: organisations willing to fundamentally restructure rather than add process on top of dysfunction.

Comparison

SAFeShape UpLeSS
Team size50–125+ (ART)2–6 per team2–8 Scrum teams
Cadence8–12 week PI6-week cyclesSprint (1–4 weeks)
Roles addedMany (RTE, etc.)NoneNone
ComplexityHighLowLow
BacklogYes (multi-level)No formal backlogOne Product Backlog
Best forLarge enterprises, regulated industriesSmall-medium product companiesOrgs willing to de-scale
RiskProcess bloatRequires strong shapingRequires org change

The Real Answer

Before adopting any scaling framework, consider whether the problem is one of coordination or one of coupling.

Conway’s Law — organisations design systems that mirror their communication structures. If your teams are tightly coupled, no framework will fix the underlying architecture problem.

Prefer autonomous, loosely coupled teams that:

  • Own a full slice of the product (stream-aligned, per Team Topologies)
  • Communicate through well-defined interfaces (APIs, contracts, events)
  • Can deploy independently without coordinating with other teams
  • Have clear ownership boundaries aligned to business domains

If teams can deploy independently, most “scaling” problems disappear. The need for heavyweight coordination frameworks is often a symptom of poor architecture and unclear ownership, not an inherent property of being large.