The solution
In 2012, Henrik Kniberg and Anders Ivarsson described Spotify scaling agile work to more than 30 teams across three cities. The visible invention was not a new process ceremony, but a vocabulary that separated delivery units from learning networks.
A squad was a self-organizing team similar to a Scrum team, but free to use Scrum, Kanban or a mix. A tribe collected related squads. Chapters linked people with similar skills within a tribe, while guilds carried shared knowledge, tools and practices across the wider organization.
The mechanism solved a familiar scaling trap. Keeping every decision centralized would slow teams; letting every team invent everything alone would destroy reuse. Spotify gave teams autonomy over method while using chapters and guilds to keep craft, architecture and practice moving sideways.
What it achieved
Let teams choose how, align them on why
Why it worked
Squads made ownership small enough for speed.
Tribes put related squads close enough to coordinate without a huge program office.
Chapters preserved professional development for people embedded in different squads.
Guilds let useful practices spread without turning them into mandatory process.
What can be applied
Autonomy needs a second structure for knowledge and standards; otherwise independent teams become isolated teams.
Aftermath
The model became influential far beyond Spotify. A 2020 open-access Springer paper describes it as a basis for methods used in other organizations, while also studying the governance work needed so autonomous squads do not create architectural bottlenecks.
FOLLOW THE EVIDENCE
The sources
- Scaling Agile with Tribes, Squads, Chapters & Guilds scrumexpert.com
- Spotify Tailoring for Architectural Governance link.springer.com