The so-called Spotify model is usually mentioned together with SAFe and Less as a scaling model. It’s not, actually. Let me explain.

Since the Spotify Engineering culture video came out in 2014, it has been taking the Agile world by storm. And rightfully so! I know very few Agile related videos which are so clear and energyzing as that two-part video. Didn’t you want to get up after watching that video and start doing some of that stuff yourself? That 27 minute-video has probably been more influential then the 10 best selling books on Agile combined.

Over the course of the last couple of years though, people have started referring to the topics (actually a subset of them, but more on that later) presented in the Engineering Culture video as the ‘Spotify Model’. And in this case, ‘model’ means ‘scaling model’, as it usually mentioned together with SAFe and LeSS. However, I would not characterize what is described in the video as a model. And definitely not as a (Agile) scaling model.

What is a scaling model?

I would describe a model as a set of principles or techniques that can be applied in different situations, locations and companies. In an Agile scaling model, you describe (somewhat abstract) how different teams work together in an organised way to deal with dependancies, shared resources and other factors that make a certain degree of cooperation between teams necessary. 
 

What is the Spotify model?

Usually, when people talk about the Spotify model they actually mean this:

(Image adapted from here)
 

The famous setup with squads, chapters etc. is not a scaling model. It’s more of an organisational diagram, consisting of autonomous teams, organised in larger units (tribes) with some structures to facilitate knowledge sharing (chapters and guilds). I personally think it resonates with a lot of people, because it seems this setup seems to find the sweet spot between making teams as independent as possible and still enable the sharing of knowledge between specialists that don’t work together on a daily basis.
 
It’s important to note that ‘just’ applying this model (appealing as it is) to your organisation by calling your teams squads and appointing some people to setup chapters and guilds might be a step forward for your organisation, but if you have ‘scaling problems’ (dependancies etc.) this will not be solved. None of the elements in the image above actually deal with Agile scaling!

How does Spotify deal with scaling then?

 Actually, there are some guiding principles mentioned in the video:
– focussing on autonomous teams as much
– further decoupling of dependancies between teams by using techniques like ‘internal open source’
– a very strong culture, which focusses on learning, allowing for mistakes and taking controlled risks
 
In here lies the real Spotify model: avoiding scaling issues as much as possible by decoupling as much as possible (loosely coupled, closely aligned’). Please note they went to great length in order to get there, included changing the architecture of their products to make the different parts more independent of each other. Although I am sure this was a costly (and painful) operation, I think doing this in another company with much more legacy in the infrastructure (a bank for example) might be practically impossible in some cases.

OK, it’s not a scaling model. So it’s bad?

None of the above is meant to discourage you from using the squad model as a blueprint for your own organisation. It might still be a step forward from most command and control structures out there. It is important to realise that just setting up squads and tribes does not make your teams autonomous. You might not be able to get rid of some dependancies between your teams on the short term or maybe not at all. It’s possible you still need techniques like Scrum of Scrums, release trains or certain teams working together in a LeSS-like model. But whatever you do, the most important consideration when doing these kind of organisation design exercises is this:
 

However perfect your organisational model seems (or maybe even is), it will need to be adapted at some point in time.

 
So don’t try and come up with the perfect scaling model, with all dependancies removed and optimised ways for knowledge sharing, coordination and communication. Instead: spend some time on thinking how to build an organisation that can adapt it’s model to changing insights, circumstances and needs.

 
Thanks for reading,

Jasper
 
 

Jasper Verdooren

Jasper Verdooren
Agile Coach | Senior Scrum Master | Scrum trainer