This is not an agile bashing article. I am a huge proponent of pragmatic agile and have been using agile-based principles from very early in my career.
That said, I’ve seen a lot of companies blindly adopting “Spotify’s agile model” without understanding why they’re doing it or having an understanding of the problems they are trying to fix.
Unless you are a Swedish streaming company, founded in 2006, then the Spotify approach is very unlikely to work for your company’s unique context and culture.
A quick recap of the now famous Spotify model
Before we start, let’s briefly explain the core concepts of the Spotify model.
Squads
Squads are simply cross-functional teams consisting of around 6–12 people, very similar to a scrum team. Nothing more complicated than that. Each squad consists of designers, developers, and business analysts, i.e. all the roles required to work end-to-end on one feature area, without having to rely on another team for success.
“Spotify had teams it called squads because it sounded cooler (not joking)!”
Jemiah Lee, Product Manager at Spotify 2020
Tribes
A group of teams organised into a department is called a tribe. A tribe may consist of 50–150 people but, ideally, it shouldn’t be more than around 100 individuals. This is simply a scaling mechanism to allow a larger number of people to work on a large feature.
Chapters
Chapters were created to bring all functional specialists from different teams into one community. This would allow them to discuss their area of expertise and their specific challenges. The chapter lead acts as a line manager for all chapter members.
Guilds
Guilds are very similar to chapters in that they are organised around a specialism, such as engineering or architecture. The difference being that a chapter is open to anyone who has an interest in the topic. This is almost the same concept as Communities of Practice in agile, just with a different name!
What are Spotify’s self-confessed issues with this model?
This model is by no means a panacea. There have been many insights from those who worked at Spotify explaining the shortcomings of their model and, it seems, the reality has not kept pace with the agile nirvana myth.
“It worries me when people look at what we do and think it’s a framework they can just copy and implement. … We are really trying hard now to emphasise that we have problems as well. It’s not all ‘shiny and everything works well and all our squads are super amazing’.”
Anders Ivarsson, co-author of the Spotify white paper
Issue 1: Engineering culture is not an organisational structure
The original content that Spotify released explaining their method was called Spotify Engineering Culture. Though they did outline an organisation structure, it was primarily about their engineering culture and their core working principles (see below for a list of these).
Issue 2: The model was an ambition and it was not fully adopted
When Spotify released their white paper it was part ambition and part reality. They were setting out a vision for the future.
“Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation. People have really struggled to copy something that didn’t really exist.”
Joakim Sundén, agile coach at Spotify 2011–2017
Issue 3: The model optimised for complete team autonomy
As the size of the teams grew, Spotify did not define a common process for cross-team collaboration. When every team had a unique way of working, and there were no guidelines on choices, the overall organisation productivity suffered.
Issue 4: Collaboration between teams was an assumed competency
As the number of teams grew it was recognised that dedicated support to guide and structure collaboration between teams was needed. Dedicated structures or processes are required to allow teams who are not necessarily linked to collaborate together.
“In articles or talks like this, it may come across that Spotify is some sort of agile nirvana where everything just works and that is simply not true.”
Henrik Kniberg, Creator of the Spotify Model
Remember that the Spotify model was created over 10 years ago, so it is very unlikely that, in light of the issues identified above, and perhaps others, that this is the exact model they are using now. Spotify is a company that is constantly learning and growing, so they will have evolved this model many times since the original white paper. However, there is still much we can learn, even if you should not apply the model directly.
The power of the Spotify model is in its engineering principles rather than its organisation design
The real magic of the Spotify model was in the engineering and product development culture they created for fast, motivated, decoupled agile teams. Over time, they developed some powerful core working principles that underpinned their high performance:
- Productivity is closely linked to motivation – Motivation has a higher impact on productivity than any other factor (see Richard Sheridan’s Joy Inc). Spotify uses the formula Productivity = Effort x Competence x Environment x Motivation.
- Balance alignment and autonomy – Spotify strives to strike a balance between alignment (central direction) and autonomy (team self-organisation). Managers paint the big picture but don’t tell people how to get there or how to solve the problems.
- Decoupled releases to reduce cycle time – Spotify changed their architecture to decouple dependencies and make releases easier and faster. This allowed for more frequent production releases that can be independent across teams.
- Trust your people – Spotify trusts and supports its people without trying to control them because they believe that most people are doing what is best for the organisation.
- Managers as servant leaders – It’s better for managers to ask teams how they can help, rather than asking people what they are working on or when they will be done.
- Maximise value over busyness – Teams generate ideas, run fast experiments and then measure the results. From this, they tweak their approach to maximise the value. Importantly, they optimise for maximising value and not just output.
- Improvement culture – Teams are encouraged to improve how they work, and have a model for what would make their lives easier and better. There are dedicated resources available to help improve the ways of working across the organisation.
- Healthy culture heals broken processes – Processes can often break but a healthy culture will lead to people fixing those problems by themselves.
- Team definition of awesome – Spotify encourages teams to talk about and decide what would make them awesome. After all, without a vision for awesomeness, you’re unlikely to get there. Spotify teams use regular ‘team health checks’ and they track improvements over time. Q: Do your teams have a definition of awesome? Do you track team health and strive for continuous improvement?
- Employee satisfaction is of the utmost importance – Spotify’s Head of People claimed that 91% of employees enjoyed working at Spotify, which he said was “of course not satisfactory”… such is the high bar that they set for themselves.
- Mistakes are OK – Spotify’s CEO explains that mistakes are expected when you are pushing for innovation. To mitigate this, Spotify has a lot of systems built in to limit the effects of failures.
“We aim to make mistakes faster than anyone else”.
Daniel Ek, Founder of Spotify
As you can see, there are some great concepts built into the model, but it is not a blueprint for agile organisational design by itself.
Iterate using inspect and adapt to create your own target model
The context of your organisation, where you are starting from, your culture, objectives and many other factors will determine the best solution for you.
Of course, you can research and borrow ideas from companies like Spotify, Menlo Innovations, Google, or other highly performing companies, but that should just be the starting point.
You have to know with clarity what problem you are trying to solve and then create a plan based on solving your unique set of challenges.
Inspecting and adapting is a core concept of agile.
Inspect is using an open mind and transparent feedback (most often performed at a retrospective) to honestly look at what is working and what is not. This could be anything from processes, team dynamics, strategy or inefficiencies, anything that impedes the team performance and reduces their motivation and ownership.
Adapt is the process of taking the themes from introspecting and finding ways to respond and improve them. Adaptation takes creativity and effort and it often takes the form of an experiment. A small test is performed with a subset of the teams to ensure that the solution is viable, before it is rolled out across the whole organisation.
This process is then repeated each time your organisation is improved and moves closer to your ideal target state of being.
Be inspired but do not copy blindly
There is a lot to like about the Spotify model, if you adopt their engineering principles and model the spirit of what they are trying to do.
Context is everything, so unless you are a Swedish music streaming company then blindly copying Spotify is unlikely to solve your problems.
However, it is very unlikely that blindly copying the model will work for you. It is important to draw inspiration from multiple sources, if you want to scale agile in your organisation.
If you want to scale agile and have more than 150 people in your team, then two good scaling models are:
If you have less than 150 people, Shape Up by Basecamp is a great model to aspire to.
Spotify is not an agile nirvana
I hope this article has highlighted that the agile engineering culture at Spotify is a lot more than just creating squads, chapters, tribes and guilds.
In fact, the Spotify Model is mainly its culture and high competency teams, not its organisational design. You can get huge benefits by adopting the principles even without implementing squads and tribes.
“In articles or talks like this it may come across that Spotify is some sort of agile nirvana where everything just works and that is simply not true.”
Henrik Kniberg
The quick version of how to scale agile
I’ll write a whole blog post on this in the future, but for now here is the quick version of how you should go about scaling agile in your organisation:
- Get clear on what problem you are trying to solve.
- Consume the best and most relevant parts of the best industry scaling models e.g. SAFe, LeSS, DaD etc. into your target design.
- Design a target state that takes best practice tailored for your unique set of challenges.
- Make changes towards your target state design.
- Inspect and adapt constantly to find improvements based on evidence.
- Make course corrections based on the feedback.
- Rinse and repeat steps 4 to 6!
References
https://blog.crisp.se/wp content/uploads/2012/11/SpotifyScaling.pdf
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
https://blog.crisp.se/2015/06/07/henrikkniberg/no-i-didnt-invent-the-spotify-model
https://www.jeremiahlee.com/posts/failed-squad-goals/
https://masterofnone.io/dont-do-spotify-model/
https://vitalitychicago.com/blog/there-is-no-spotify-model-for-scaling-agile/
One thought on “Why Copying Spotify’s Squads and Tribes Model Probably Won’t Work for You”
Comments are closed.