Curious Pandas

Frameworks for many teams

SAFe, LeSS, Scrum@Scale and the "Spotify model" each promise a way to run many teams. Read each in its own words, read its critics in theirs, and learn why copying another company's snapshot is the most common way to get it wrong.

16 min+40 XP for finishing

One team can agree how to work in a room. Fifty teams building one product can’t, and that’s the gap scaling frameworks try to fill. There are several, they disagree with each other, and most organisations end up running a variation of one. The useful skill is reading each one’s claims, and its critics’, for what they are.

Each in its own words

  • SAFe (Scaled Agile Framework) groups teams into an Agile Release Train of “50 -125 people” who plan together in PI Planning, held “every 8-12 weeks”. It is the most prescriptive of these, with roles, events and configurations at several levels. Its current versions are called “Core SAFe” and, added in June 2026, “AI-Native SAFe”.
  • LeSS (Large-Scale Scrum) keeps one Product Owner and one Sprint for “Up to eight teams (of eight people each)”, and adds as little as it can.
  • Scrum@Scale, from Jeff Sutherland, scales Scrum with Scrum itself and aims for a “minimum viable bureaucracy”. Its blunt line: “If an organization cannot Scrum, it cannot scale.”

SAFe’s site claims results like “30 – 75% faster time-to-market”. The page gives no sample, baseline or method, so treat it as a vendor’s claim, not a measurement. We link to SAFe’s own pages rather than reproduce its diagrams, which its terms restrict.

The critics, dated

The best-known critiques of SAFe are from 2013 and 2014, written about the SAFe of that time, years before its current versions. Ron Jeffries is the fairest single voice: if an organisation “actually did what it said, they would likely prosper”, but “SAFe isn’t really Agile in its heart”. You’ll also see Martin Fowler’s 2018 “Agile Industrial Complex” talk cited as a SAFe critique. It never names SAFe, so don’t use it that way.

The “Spotify model” was a snapshot

In 2012 Henrik Kniberg and Anders Ivarsson described how Spotify organised its teams into squads, tribes, chapters and guilds. Their paper called it “a journey in progress, not a journey completed”. Many companies copied it as a framework anyway. In 2020 Jeremiah Lee, who worked there, described how it played out, including a former Spotify coach’s line that “Even at the time we wrote it, we weren’t doing it” (quoted second-hand in Lee’s article). Kniberg himself said in 2015 that it “wasn’t actually intended to be a generic framework”. He also said he had “yet to see a case where a company ended up in a worse position” after borrowing from it, so the story isn’t simply a failure either.

Check yourself+10 XP

A framework vendor's website says customers see '30-75% faster time-to-market'. What's missing before you can rely on it?

Check yourself+10 XP

What did the 2012 Spotify paper say about the model it described?

Sources

Finished reading?

Missions and quizzes above earn their own XP. This marks the lesson done.