<p>Scaling Agile @ Spotify
with Tribes, Squads, Chapters & Guilds
Henrik Kniberg & Anders Ivarsson
Dealing with multiple teams in a product development organization is always a challenge!
One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite
having scaled to over 30 teams across 3 cities.
Spotify is a fascinating company that is transforming the music industry. The company has only existed 6
years and already has over 15 million active users and over 4 million paying. The product itself can be
likened to “a magical music player in which you can instantly find and play every song in the world”.
Alistair Cockburn (one of the founding fathers of agile software development) visited Spotify and said “Nice -
I've been looking for someone to implement this matrix format since 1992 :) so it is really welcome to see.”
So how is this managed?
We have both presented at conferences and been caught in engaging discussions around how we work at
Spotify and how the company handles agile with hundreds of developers. Many people are fascinated by
this, so we decided to write an article about it.
Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article
is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the
time you read this, things have already changed.
The basic unit of development at Spotify is the Squad.
A Squad is similar to a Scrum team, and is designed to feel like a mini-startup. They sit together, and they
have all the skills and tools needed to design, develop, test, and release to production. They are a
self-organizing team and decide their own way of working – some