The Spotify model for scaling agile has been making the rounds as something to aspire to - but does the model live up to the hype? It’s been 10 years since the Scaling Agile @ Spotify whitepaper was published - so how much can we still learn from Spotify?
What is the Spotify model?
Like all good stories, we have to start at the beginning. Back in 2012, Henrik Kniberg and Anders Ivarsson released a whitepaper detailing Spotify’s methodology for scaling their agile organizational design.
This simple method of agile team organization took the agile world by storm and many companies have since used the Spotify model to shape their business model. Even though this whitepaper was merely meant to be an example of agile structuring - not a guidebook!
Spotify’s approach was to focus on two key aspects: culture and network.
Elements of the Spotify model
So you might be wondering how teams are structured in the Spotify system? Well, there’re a lot of terms to learn so let’s get into it!
A squad is a small cross-functional, autonomous team of roughly 6-12 people. These groups exist as mini-startups and work on one feature area and mission each. Squads don’t have an assigned leader but they all have a product owner to help prioritize work and an agile coach to, well, coach the squads to continuously improve.
Each squad is encouraged to dedicate around 10% of their time to hack days, which are focused on innovation, trying out new ideas, and brainstorming in groups.
Tribes are groups of squads that work together on larger-scale projects - these are normally composed of around 100 people (give or take). Each tribe has a tribe lead that helps to create the best environment for each squad to thrive.
A trio is the combination of a tribe leader, a product leader, and a design leader. Some tribes have a trio to keep all of these perspectives aligned in larger tribe projects.
An alliance is a group of trios that work together to allow multiple tribes to work together on big projects that are larger than a single tribe.
Although most work is done in squads (with cross-functionality in mind) it is still important to have discussions within specialties - this is where the Chapter comes in. Chapters are groups of people with the same specialty (for example, all of the software engineers). This allows specialties to discuss similar problems and stick to standards across projects.
The chapter lead is the line manager for chapter members - with all the responsibilities associated with that role. But they are also still part of a squad and day-to-day work, keeping them aware of projects going on within Spotify.
The above groups all deal in workflow-related groups - a guild on the other hand is voluntary. Guilds are based around interest groups - some guild members will work on those sorts of projects or other members may just have an interest in that topic. Guilds are more of a voluntary group that meets up, discusses, and solves problems around their area of interest.
Why use the Spotify model?
What’s so good about the Spotify model? Well a few things, but there are drawbacks too. This model worked for Spotify back in 2012 but more recent reports suggest that Spotify no longer uses it.
This model is essentially a snapshot of agile in 2012 and is way more flexible than many of the more popular frameworks now, such as the scaled agile framework. It really depends on your company whether this more flexible model is a better fit for your organization.
This model won’t work for every company - but these pros and cons might help you to decide if the Spotify model would benefit your company.
Pros of the Spotify model
There are many benefits of the Spotify model - a few of these are listed here.
- Less formal - There are less formal management systems in this model which may benefit some teams.
- Self-managed and autonomous - Teams have ownership over what they do and can manage their time as they see fit, to meet their feature objectives.
- Fewer bottlenecks and red tape - Since squads are mostly self-sufficient there are fewer hold-ups and more trust leads to fewer restrictions for teams. This leaves them more space to innovate.
Cons of the Spotify model
Not everything is great about the Spotify model though - here are some cons of the model to be aware of.
- Needs editing - this is called the Spotify model for a reason, it’s not made for any other organization so make sure you edit it for your company’s needs.
- Risk to system architecture - Everyone working on individual features can make it hard to keep track of the full system architecture.
- Not suited to every organization - Not every organization will thrive under this model - it may even cause some companies more problems than it solves.
- Not extensive - This model doesn’t really cover all of the ins and outs of each problem and how to solve it. Spotify stopped using this method at some point so there must be some more murky issues.
- Not meant to be a guide - As we said at the beginning this model was originally published purely as an example, not a guide. So definitely take its advice with a grain of salt.
Top tips for implementing the Spotify model
If you still think the Spotify model will help your business, you might be wondering how you can implement it. Well here are our top tips for making the most of the Spotify model!
- Don’t copy and paste - This model will only work for your company if you take some things, leave others and edit when needed.
- Make sure it fixes your team's problem - Similarly, make sure the benefits of the Spotify model solve the root of your team’s problems - otherwise you might be creating more!
- Keep adjusting - This is not a static model, keep adjusting and tweaking to make it work for your always-changing team.
- Focus on culture and network - Don’t forget the key principles of the Spotify model - culture and network. Without these key aspects, the model is just a matrix model with different terms.
- Don’t make it a chore - It’ll be difficult to reschedule your company overnight - so don’t. Slow down and take small steps to ensure your team doesn’t feel overwhelmed. Moving too fast will lead to people dragging their feet!
Although the Spotify model may not be used by Spotify today, there are certainly lessons to be learned from the way agile was successfully scaled using this approach.
For more agile frameworks check out this article!
And you can get access to our entire catalog of templates and frameworks by becoming a PLA member.👇