What is the Agile Spotify Model?
With an astounding 286 million users, Spotify is one of the world’s largest and most successful audio streaming services. Spotify owes its success to the company’s unique management strategy that helps to improve team efficiency.
As Spotify’s engineering teams worked to enhance their agility, they recorded their efforts and shared their knowledge. Now, their documented practices known as the Spotify Model have transformed the way many software companies structure their work.
This post discusses the Spotify model, its key components, and what we learn from Spotify’s scaled agile framework.
What is the Spotify Model?
The Spotify model is a people-centric, autonomous approach to scaling agile that helped Spotify scale its teams and grow the company. In Spotify’s infancy, the company used agile principles, in the form of Scrum teams to guide their work.
As the company grew, teams realized that standard Scrum practices got in the way of their progress. They decided to toss the Scrum rule book and develop their own approach to agile methodology.
Credits: Atlassian
Spotify devised its own set of rules that matched its working style and what resonated with its work culture. The company’s principles became more important than its practices. As a result, Agile was greater than Scrum. Titles like ‘Scrum master’ became ‘Agile coach’. They also used terms like ‘squad’ instead of ‘Scrum team’.
Their key objective became autonomy. They aimed to decentralize the decision-making process to cut down on time wastage.
The Spotify model originates from the whitepaper Scaling Agile @ Spotify with Tribes, Squads, Chapters, and Guilds published by Henrik Kniberg and Anders Ivarsson in 2012.
The industry recognizes Henrik Kniberg as the model’s “inventor,” but he is adamant that it isn’t true. He’s likewise quick to point out that the model was never intended for other businesses to replicate or apply themselves. However, the introduction of the Spotify model sparked curiosity in many organizations. Since then, various companies have idealized and praised the Spotify model for its simplicity.
Key Components of the Spotify Model
The Spotify model thrives on simplicity. The lightweight framework promotes autonomy within all Squads and empowers individuals to collaborate with their colleagues.
Tribes contain Squads for specific tasks. Across Squads are Chapters where employees with similar skills share information with other Squads. Guilds are groups of employees who share interests in a particular field.
Below are the key elements that distinguish the Spotify model from traditional scaling frameworks:
Squads
Squads are the most basic unit of agile development. They are cross-functional teams comprising 6-12 people. Squads are responsible for features, with each Squad focusing on delivering a specific feature.
Squads are self-organizing, although they receive support and guidance from an agile coach and a product owner.
Every Squad has its own long-term mission and must decide on the framework they need to achieve success. Scrum, Kanban, and other agile methodologies are examples of frameworks that Squads use to meet their goals.
The Spotify model adopted this form of autonomy to increase productivity and streamline the development process.
While Squads do not limit themselves to strict frameworks, they do follow lean development principles such as releasing minimum viable products (MVP) and A/B testing. This is where agile coaches come in. They guide Squads through the agile product development process and ensure they build the product in line with strategic goals.
Tribes
Even though Squads function on their own, they don’t work in isolation. Different Squads’ features overlap with each other and force teams to become interdependent. The Spotify model does not work with handoffs since they slow down the entire process. Thus, the Spotify model introduced Tribes.
A Tribe forms when multiple Squads work together on the same feature area. Tribes develop alignment among Squads and consist of 40 to 150 employees to maintain alignment (using Dunbar’s Number).
Each Tribe has a Tribe Lead who assists with Squad coordination and collaboration. Besides the Tribe Lead, who is there to ensure everyone has the resources to complete their work, there is no official hierarchy within the Tribe.
Chapters
Spotify implemented Chapters to boost collaboration between experts in their field. Specialists, like front-end developers, meet up to share information and problem-solving techniques. They gather feedback from each other to ensure they follow engineering standards throughout the development process.
Specialists from all Squads within a Tribe form a Chapter. Similar to a family, chapters inform other members of their progress during daily standups.
Chapters also work together to help members deal with any potential obstacles in their day-to-day work. The open company culture and regular, informal sharing of information empower business agility.
Guilds
Guilds are self-organizing associations of employees who share similar interests. They have no specific practices or set of rules that they follow. Guilds welcome people from different Tribes to join, as long as they have an interest in a particular Guild’s focus.
Unlike Chapters, which belong to a specific Tribe, Guilds exist across different Tribes. A Guild does not have a formal leader or formal process. Instead, someone volunteers to be the Guild Coordinator and assists in bringing people together.
Not everyone belongs to a Guild as they are voluntary. Take, for example, interface development. Everyone involved in interface development joins the Guild. Even individuals interested in interface development who don’t require it for their day-to-day job join the Guild to learn more on the topic.
Trios
Trios are a later addition to the Spotify model. Trios are also known as TPD Trios since they consist of a Tribe Lead, Product Owner, and Design Lead.
They work together to enable agile between the three perspectives. Each Tribe has its own Trio which keeps everyone focused on the task at hand and aligned with agile principles.
Alliances
Tribes have the opportunity to work together on big projects as their company scales. Big projects require Alliances between different Trios.
Three or more Trios collaborate to discuss project management strategies and ensure alignment between their respective Tribes.
Trios are also a revised edition of the Spotify model. At first, Spotify struggled to follow its new scaled agile framework when it came to big projects. However, once they implemented Trios and Alliances, big projects became more manageable.
Strengths of the Spotify Model
Spotify needed Squads to work fast, deploy software, and do it with minimal setbacks when they transformed how they scaled agile. As they refined their model, they discovered advantages along the way. Companies looking to implement the Spotify model experience a variety of organizational benefits as long as they do so from their own cultural perspective.
High Degree of Autonomy and Alignment
The Spotify model places a strong emphasis on decentralizing decision-making and delegating to Squads, Tribes, Chapters, and Guilds.
Henrik Kniberg and Anders Ivarsson designed the model around a company culture focused on autonomy and collaboration. Thereby trusting and empowering teams to complete projects using whatever agile methodology they see fit.
The structure of the Spotify model allows Squads to make instant decisions about their work. Although they rely on agile coaches to keep them aligned with the strategies of the organization, Squads implement changes to code on their own accord.
Spotify’s agile product development rose to the pinnacle of the audio streaming world thanks to the benefits of this decentralized decision-making culture. They no longer had to rely on time-wasting sign-offs before releasing software.
Balance of Consistency and Flexibility
For the Spotify model to work, teams need to release updates often and in small increments. This presents Squads with flexibility and consistency since they don’t work towards one gigantic release. Big releases equal potential for big failures. So instead, Spotify implemented something called a Release Train.
The Release Train functions like a normal train and ‘leaves the station’ once a week. This allows teams the opportunity to ship their completed software on the train for continuous improvements.
Spotify uses another ingenious tool called a Release Toggle which allows them to release an update for testing but removes the update if the software doesn’t function as expected.
During testing, Spotify releases updates to a small percentage of their clients and in so doing they minimize their ‘blast radius’ if the new code malfunctions.
Setbacks of the Spotify Model
With all the promise of the Spotify model, it turns out that it didn’t come without its difficulties.
As the company grew, Spotify struggled to determine a common structure for communication within a cross-functional team. Since each team chose its own framework, the collaboration between teams suffered and productivity slowed.
Sure enough, Spotify no longer uses the Spotify model. So what caused the audio streaming giant to move away from the model?
Difficulty With Big Projects
Since the Spotify model required consistent, smaller releases to function they discovered a knot that proved difficult to untie.
The Spotify model became more complex than its creators anticipated as the company and its ambitions evolved.
Practices intended to improve agility instead hampered it. The problem with the model is that it worked on assumptions.
When Spotify scaled agile, they assumed that all their employees were cross-functional, collaborative superstars. In reality, team members struggled with internal communication and didn’t agree on the methodology to use to complete their given project.
The fixation on autonomy suffocated cross-team communication. The communication structures of the teams did not align since each had its own method of working. As a result, the larger the project, the more teams there are, resulting in low-quality communication.
One Size Doesn’t Fit All
Anders Ivarsson, the co-author of the Spotify whitepaper, said, “It worries me when people look at what we do and think it’s a framework they copy and implement. … We are trying hard now to emphasize we have problems as well. It’s not all ‘shiny and everything works well and all our squads are super amazing’.”
When the Spotify whitepaper first made its way into the world, organization after organization attempted to reap the benefits of the simple framework the model described. Much to their detriment, they didn’t get it right. The methodology described in the whitepaper seemed so easy to follow and implement. If it worked for Spotify then it’s bound to work for them too, right?
Wrong.
Company culture plays a big role when scaling agile. Organizations must take their existing framework into consideration before choosing to adopt the Spotify model. Many didn’t think about how a change in their traditional scaling frameworks impacted the company.
For some, it worked up to a point and then became far too complex. The focus on autonomy proved difficult for industries where there needed to be some form of hierarchy to make decisions.
What do we Learn From the Spotify Model?
Although the initial Spotify model had its issues, there are positives to reflect on. Organizations that tried to adopt the scaled agile framework and failed ended up learning more about themselves and their company culture. Spotify themselves learned more about how people function and that even the simplest of frameworks become complex as organizations grow.
What do we learn?
Celebrate Failure
Scaling agile in organizations isn’t a walk in the park. It’s a continuous process of trial and error to find what works for your company. Learning from failures is an essential component of improvement.
Spotify trialed multiple versions before getting to the framework that they use today.
Empower Many, Not Everyone
The Spotify model gave full autonomy to Squads. It didn’t work for all teams and that brought with it an important lesson. Full autonomy isn’t the answer. There needs to be a form of hierarchical structure for decision-making and delegating.
Furthermore, teams require a common framework for high-quality communication and collaboration.
Understand the Model, Don’t Copy It
This is where most organizations went wrong. Instead of trying to understand the model and tweak it to their own work culture, companies implemented it on a full scale.
Companies who want to gain from the Spotify model must consider introducing changes in increments. Test with several perspectives until you find what works best for your team.
Spotify Model: Key Takeaways
The Spotify model attempted to simplify the scaled agile framework. In the initial years, it helped Spotify to reach the success it knows today. Many organizations marveled at the coolness of the simple practices that Spotify implemented.
When other companies tried to emulate the model, it didn’t go as planned. Yet, a silver lining presented itself in that companies got to learn themselves and their style of work better.
At the end of the day, companies found their own way of organizing around work and reached their own success.
The final takeaway: there is no shortcut to success.
