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.
