Spotify: The Agile Nirvana?
The Spotify Model has become a standard approach in the agile world - but what impact did it have on Spotify?
Hello, and welcome to the second edition of the Velocity Agile newsletter! Welcome to the 16 new subscribers who have joined us since last week. If you like this newsletter, please pass it on to any friends or colleagues who might be interested. Thank you!
Not many startups have managed to become the global leader like Spotify has achieved in music streaming. Despite Apple Music, Youtube and Amazon Music all trying to dominate the estimated $26bn a year industry1, Spotify is now the undisputed leader with an estimated 32% of market share2. All of this whilst being an independent startup since its inception in 2006, with none of the network effects that assist the other players. How has it achieved such roaring success?
What is the Spotify Model?
One reason for their success from a technology perspective is the Spotify Model. The Spotify Model describes how Spotify Engineering organises itself around agile principles. They care so deeply about this that CTO Daniel Ek describes himself as the first agile coach at Spotify.
Lets recap the model from the source of truth - the Spotify Engineering Culture videos and the Scaling@Spotify whitepaper.
The main focus of the Spotify Model is autonomous teams that have all the skills they need to deliver value. These are called squads. When multiple Squads coordinate within each other on the same feature area, they form a Tribe. Tribes help build alignment across Squads and typically consist of 40 - 150 people in order to maintain alignment (leveraging what we call Dunbar's Number). Each Tribe has a Tribe Lead who is responsible for helping coordinate across Squads and for encouraging collaboration.
Even though Squads are autonomous, it’s important that specialists (e.g. Javascript Developer, DBAs) align on best practices. Chapters are the family that each specialist has, helping to keep engineering standards in place across a discipline. Chapters are typically led by a senior technology lead, who will also be the line manager for the team members in that Chapter.
Team members who are passionate about a topic can form a Guild, which essentially is a community of interest. Anyone can join a Guild and they are completely voluntary.
All of this is summarised in this nifty diagram you will find everywhere in discussions of the Spotify Model.
But wait! This only describes the roles. Really, the Spotify Model is about the culture of empowering teams to make decisions themselves, and prioritising interaction of people over process. The mantra in the early days of Spotify was the same as Facebook - ‘Move fast and break things’. The Spotify Model set them up to achieve this.
Why did Spotify Do This?
Spotify adopted this model primarily to encourage autonomy in its teams. As a startup in a crowded market, the main advantage of Spotify was speed. This could only be achieved if teams were able to make their own decisions and act fast. They prioritised this over everything else.
The approach also encouraged servant leadership. At first look, it seems there are lots of managers per individual contributor in technology (credit: Joakim Sundén):
But rather than adding reporting overhead, these managerial roles take toil away from the engineers and allow them to focus on engineering. They are there to support the engineers and help them to succeed as a team.
Incidentally, it had an unintended benefit of helping Spotify hire some of the best agile coaches in the world due to the reputation the Spotify Model helped to foster for agile excellence!
What were the problems?
The Spotify model has been far from perfect. Whilst solving for the problems stated above, it introduced a litany of issues, as described by former Spotify Agile Coach Joakim Sunden.
Ownership of team delivery - no one had clear accountability for delivery of the teams. This sat between product and engineering, with no clear ownership. This often meant deadlines slipped as no one was accountable for hitting them.
Matrix Management - engineers were managed by their chapter lead rather than someone related to their squads and tribes. This could lead to misaligned incentives between who sees their day-to-day work and who manages their performance.
Agile engineering practices - Spotify had the same issue as nearly every other company - consistently delivering engineering practices such as TDD, maintainable code and pair programming.
Disciple of agile process - despite agile being a core focus, there was still a lack of discipline around the scrum process. Missing sprint reviews, carrying work over between sprints and not following up on actions, were all common problems.
The real lesson
Spotify never expected the model to become something that is copied so widely - they were simply sharing their experience of what worked for them. It is far from a ‘silver bullet’ to solve all their problems - developing the right agile culture and principles is still an uphill struggle at Spotify.
The key lesson of the Spotify experience is their willingness to experiment and try new org structures within the context of their company. They took ideas from others and created their own solution to best fit their problem. This helped them build one of the most iconic products of the 21st century, that continues to iterate to meet new market demands around customer insights and podcasts.
The true lesson is how a culture of experimentation around agile principles can drive massive success if the whole company commits to it.
Enjoyed this? Every week I send a newsletter with a real-world case study or example of how to improve your agile delivery. Subscribe to get these updates right to your inbox!
Additional References
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model
https://engineering.atspotify.com/2021/05/27/achieving-team-purpose-and-pride-with-scrum/
https://engineering.atspotify.com/2020/05/18/my-beat-alia-rose-connor/
You hit 2 on key points:
- autonomous **teams that have all the skills** they need to deliver value, I’ll add and people
- created their own solution to best fit their problem (and this should change from time to time
Something I think that is highly missed in this age of Agile is that our ways of working schools change based on what is being done or needs to be delivered but for some reason everyone wants to always only do only Scrum — that’s not agile! ☺️