Thought Leaders

Spotify Scaling Agile Model

spotify

The Spotify model is a people-driven, autonomous framework for scaling agile. The model emphasizes the importance of culture and network and is implemented through Squads, Tribes, Chapters, and Guilds. The foundation of the model is the squad and it acts like a Scrum team.

History of the Spotify Model

Spotify has become a popular music player and well known for providing original and limitless collections of music content. It was launched in 2008 and it became a large company with 1,600 employees.

It owes their success to their deeply-rooted agile methodologies and utilization of Agile Scaling. The strategy is called Spotify Tribe.

Initially, the company started with scrum methodology, when it had fewer employees, but as it started to grow it implemented agile scaling. Now it has has 30 agile teams spread across four cities in three different time zones.

Adopting a unique Agile Scaling Method has not only made Spotify achieve its goals quicker but also helped to develop employee mindset.

How did Spotify managed growth as it scaled?

Spotify started with scrum, but soon it started applying agile principles in the following way:

1) Squads

2) Tribes

3) Chapter

4) Guild

5) Trio

6) Alliance

7) Chief Architect

Here is a detailed explanation of the components mentioned above

Squads: The Basic Unit of development at Spotify is the squad. Generally, a squad is similar to a scrum team and is designed to feel like a small start-up business. In an organization, there can be multiple squads and each squad consists of 6-12 people.

Each squad is dedicated to working on one specific area. Everyone in a squad usually sits together and they have all the skills and tools needed to design, develop, test, and release into production.

The squad is an autonomous, self-organizing and self-managing. Each of the squad has complete freedom to choose their agile methodology. So some squad uses Scrum sprints, some use Kanban and some uses mix of scrum and kanban. Sometimes to release early, squads apply the Most viable product (MVP) technique too.

Each squad has a long-term mission such as building and improvising the product. All the squads always have an agile coach, that helps improve their way of working. There is a product owner who defines the vision of the feature area.

The Agile coach conducts retrospective and sprint planning meetings are kept optional. Each squad has direct interactions with stakeholders and no blocking dependencies on other squads.

Most of the squads have an awesome workspace including a desk area, a lounge area, and a personal “huddle” room. Almost all the walls are whiteboards.

The Squads are encouraged to spend 10% of their time on “hack days”. During hack days people do whatever they want, typically trying out new ideas and sharing with their peers.

Hack days are not only fun they are also a great way to stay up-to-date with new tools and techniques and sometimes lead to important product innovations.

A high-level insight of a Squad:

  • Product owner – The squad has a dedicated product owner that prioritizes the work and takes both business value and tech aspects into consideration.
  • Agile coach – The squad has an agile coach that helps them identify impediments and coaches them to continuously improve their process.
  • Influencing work – Each squad member can influence his/her work, be an active part in planning and choose which tasks to work on. Every squad member can spend 10% of his/her time on hack days.
  • Easy to release – The squad can (and does!) get stuff live with minimal hassle and sync.
  • The process that fits the team – The squad feels ownership of their process and continuously improves it.
  • Mission – The squad has a mission that everyone knows and cares about, and stories on the backlog are related to the mission.
  • Organizational support – The squad knows where to turn to for problem-solving support, for technical issues as well as “soft” issues.

Pictorial representation of a Squad

spotify squad

Tribes: Multiple Squads that work on a related feature area make a Tribe. The Tribe can be seen as an incubator for the squad mini-startups. The tribe has a fair degree of freedom and Autonomy.

A Tribe may consist of 42-150 people but ideally, a tribe should have a maximum of 100 individuals. Each of the tribes has a lead who is responsible for creating a productive and innovative environment for the squads. The squads in a tribe are physically in the same office and the tribe lead can be part of the squads as well.

Tribes hold gatherings regularly, maybe an informal get together where they represent their work to the rest of the tribe on what they have delivered and discussed the lessons learned.

Tribe leaders pay close attention to the squad dependencies and analyze to what extent those dependencies are blocking or slowing the squad down. Then tribe leaders discuss the ways to eliminate the problematic dependencies, especially blocking and cross-tribe dependencies.

Pictorial representation of a Tribe

Chapter: The Chapter is a small family of people having similar skills and working within the same general competency area, within the same tribe. The chapter is a kind of glue that keeps the company together, it gives some economies of scale without sacrificing too much autonomy.

A Chapter consists of individuals from different squads to be grouped into one and formed within a tribe. A Chapter lead is also a line manager of the chapter members and supports them in their personal growth and specific challenges.

Each chapter meets regularly to discuss their area of expertise and their specific challenges. The Chapter Lead is also part of squad and tribe and involves in day-to-day work. A chapter can be like the testing chapter, the backend chapter, the frontend chapter, and the web developer chapter.

Pictorial representation of a Chapter

Guild: An informal group constituted of people from different tribes. A Guild is a more organic and wide-reaching “community of Interest”. A guild is a group of people that share knowledge, tools, code, and practices. A Person from any squad, chapter, or tribe can be part of a guild.

The purpose of having a chapter and a guild is the same; ensuring transparency by solving problems and keeping teams aligned and focused. Whereas the chapters are always local to a tribe, while a guild usually cuts across the whole organization.

A guild often includes all the chapters working in that area and their members e.g. Web developer guild includes all the web developers in all web developing chapters, but the benefits of having guild are anybody, who is interested can join any guild.

Now I will explain in simple terms with an example as to how a guild works. There is a tester from a particular squad, let’s say from squad A, who is struggling with a problem.

There is another tester in squad B who can easily solve the same problem because he has already done it, so if both of them are in the same chapter then they can share their problem and find a solution.

But if both of them are not in the same chapter, then they would have a guild i.e. guild for testers, so both the testers can share their knowledge and help each other.

As we have understood that each chapter meets regularly to discuss their area of expertise and discuss their challenges. But a guild usually conducts workshops and the guild workshops are like hackathon and guild workshops are very critical activity for guild members.

Pictorial representation of a Guild

Trio/Alliance Lead: A Trio is formed when for every tribe there is a design, product area, and a tribe lead.

Alliance: A combination of three trios makes an alliance. it is led by product, design, and a tribe leads.

Pictorial representation of a Trio & Alliance

Chief Architect: A critical member of an organization that defines the architectural vision, guides in design, and deals with the system architecture dependency issues.

***Please check out the below video to have a detailed understanding of the Spotify Scaling Agile model. This video was prepared by Henrik Kniberg in 2 parts. I have compiled them to have better visibility and understanding.***

Distribution over Delegation: The Whole system greately changes the leadership structure within the company- especially as squads have no hierarchy.

But this can be a daunting prospect for all the traditional company as spotify model required to have agile coaches to help organizations set it up for.

Usually while implementing Agile the following concerns will bound to raise i.e. how do you ensure employees aren’t slacking off? if everyone is equal, how do workers map a career path? Who is in place to delegate tasks?

But we all have to remember that the adoption of agile processes increases productivity by a massive 87%. so the number itself answer everything.

If productivity increased by 87% then it’s obvious relates to the team and it’s members and it happened only because when they feel motivated. They feel motivated as everyone is on a leel playing field working towards a commonly defined goal.

In addition, process will be quicker and more efficient, in return employees will benefit from a more inclusive and dynamic company culture.

SAFe v/s Spotify

The SAFe framework 4.5 is a lean-agile framework for working for several scrum teams together within the same structure. It offers a complete set of tools that range from scrum teams to portfolios.

It also offers courses for its implementation and certifications to create coaches of the framework. SAFe offers a complete and detailed framework that reassures its interlocutors. But some experts see it as a framework much too detailed.

SAFe tells you how to work, how to coordinate, how to train, and how to put it in place. Whether we like it or not, we must admit that it is incredibly complete. There is a small lean side to want to define everything and optimize. Overall SAFe is a heavy framework.

Spotify had set up a large-scale agile model which later on became very famous in the name of the Spotify model. It was Henrik Kniberg and Anders Ivarsson who communicated it in 2012.

However, this model has become a reference and many companies are inspired by it from 2012. The Spotify model doesn’t want to be a big toolbox. The Spotify emphasizes the need to create many interactions to limit the silo side created by the squad.

It will be essential to define how each team has to work in a general way or by leaving the autonomy to the teams at 100% usually Spotify model doesn’t detail anything at this level.

Moreover, the Spotify model doesn’t bring any solution to manage the portfolio unlike SAFe. Spotify provides complete freedom and the team has to define everything. Overall Spotify is a lightweight framework.

Conclusion

There are no losers or winners, the SAFe framework and the Spotify model both have their advantages and disadvantages. The Spotify model offers some interesting concepts that you can use.

However, it will be essential to have an agile coach to help you set up. Whereas SAFe offers training and certification to understand their framework and to create coaches who can guide the team on the framework.

One side Spotify provides complete freedom to the team to decide their way of working and on the other side, SAFe will ask you to follow a set of recommendations for its implementation, which is much more reassuring by its strict framework side.

The best option would be to use a mix of SAFe and Spotify model and it can produce a very interesting outcome when we blend the Spotify model with SAFe tools.

***Here a video that explains and demonstrates the Spotify Scaling Agile model in detail with examples. Please check out the same to have a better understanding of the Spotify Scaling Agile model. ***

People should be wondering why I am writing this article when people are talking about a disciplined agile, Scaled agile framework. The reason why I am writing this article because I find the Spotify model is different and innovative.

As it’s easy to follow a framework or methodology which is already defined but using agile principles and manifesto creating something on your own and then the rest started following it, is quite impressive.

References:

https://medium.com/scaled-agile-framework/exploring-key-elements-of-spotifys-agile-scaling-model-471d2a23d7ea

https://www.myagilepartner.com/blog/index.php/2019/05/31/safe-vs-spotify/

https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Abhishek Mishra
Related Thought Leaders
Related sized article featured image

The answer may lie within your team.

Marco Favaloro
Related sized article featured image

Martin Coulter