What is the Spotify model for Agile?

The other day someone said to me  that “they use the Spotify development model”, and I said “you who the what now?”. It was a super productive conversation that I am quite proud of.

So… in order to look like less of a n00b in the next conversation, what is the “Spotify development model”? Well, it turns out the Spotify came up with a series of tweaks to the standard Agile process in order to scale their engineering teams. If you google for “spotify development model” or “spotify agile” you’ll get lots and lots of third party blog posts about what Spotify did (I guess a bit like this one), but its surprisingly hard to find primary sources. The best I’ve found so far is this Quora answer from a former VP of Engineering at Spotify, although some of the resources he links to no longer exist.

Here’s a quick summary though:

Squads: the basic unit of development team. Squads sit together, and have all of the tools and skills to release a feature to production. Squads self-organize and can choose in what way they work. For example some might use Scrum, while others might choose Kanban. Squads have a long term mission, but its usually a shared belief — “we will improve the search interface” for example. Squads don’t have a designated leader, but they do have a Product Owner.

An aside, squad interdependencies: Squads are meant to feel like independent small startups, so the dependancies between Squads are closely managed. You can’t completely eliminate dependancies if you’re going to build big things, but you can actively track those dependancies and make sure that they’re consciously managed.

Product Owners: each Squad has a Product Owner, who is responsible for prioritising the work of the Squad. The Product Owner also keeps in touch with other Product Owners in associated areas to ensure that a coherent overall product is being built.

Tribes: a Tribe is a set of Squads which work in related areas. So for example it might be all of the Squads which work on the mobile client, or all of the Squads dealing with backend infrastructure. Tribes are usually co-located (the same building), and are kept to less than 100 members to ensure that everyone knows each other. Tribes hold regular gatherings where they show off what they are working on, what they have delivered, and what others can learn from them.

Chapters: if you’re the only operations person in your Squad, then that can be an isolating experience and stops you from learning from other operations people’s experiences. To solve this, people with similar skills are also grouped into an overlay called a Chapter. Chapters meet regularly like Tribes, but Chapters are also where you get your people management from — the Chapter Lead is your people manager and does all the usual HR stuff to ensure your career needs are being met. At Spotify Chapters are a sub-unit of a Tribe, you don’t have Chapters which cross Tribe boundaries.

Guilds: Guilds are similar to Chapters, but aren’t skills based. They’re people with common interests, and can cross Tribe boundaries. An example of a Guild might be all your web developers, or all your Prometheus aficionados.