The Spotify model is a people-driven, autonomous framework for scaling agile. This model emphasizes the importance of culture and network. This methodology uses Squads, Tribes, Chapters, and Guilds, whereas the foundation of this model is the squad and it acts as the Scrum team.
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 has become a large company with having 1600 employees.
They owe their success to their deeply rooted agile methodologies and utilization of the Agile Scaling in their way. This method is called Spotify Tribe.
Initially, the company started with scrum methodology when they have fewer employees but when they started to grow they thought of scaling thus they started utilizing agile scaling in their way. Now they have 30 agile teams that are spread across 4 cities in 3 different timezones.
So by adopting a unique Agile Scaling Method has not only made them achieve their goals quicker but it also helps them in shifting the mindset of the people.
Spotify has initially started using scrum, soon within no time their scope of work and resources increases thus they started applying agile principles in the following way.
7) Chief Architect
Squads: The Basic Unit of development at Spotify in the squad. Generally, a squad is similar to the scrum team and is designed to feel like a mini-startup. In an organization, there can be multiple squads and each squad consists of 6-12 people.
Each squad dedicated to working on one specific area. All the people in a squad usually sit together and they have all the skills and tools needed to design, develop, test, and release to 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:
Pictorial representation of a 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.
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.
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.