Spotify is an autonomous, people-driven framework that allows for agile scaling. The model emphasizes culture and network. It is implemented via Squads, Tribes and Chapters, as well as Guilds. The squad is the foundation of the model and acts as a Scrum team.
The history of the Spotify Model
Spotify is a well-known music player that provides unlimited music content. It was founded in 2008 and has grown to be a large company employing 1,600 people.
Their deep-rooted agile methodologies and use of Agile Scaling are the key to their success. Spotify Tribe is the name of the strategy.
The company began with scrum methodology when it had fewer employees. However, as it grew, agile scaling was implemented. It now has 30 agile teams in four different cities and three time zones.
Spotify has been able to achieve its goals faster by adopting an innovative Agile Scaling Method. This has also helped to change the mindset of its employees.
How did Spotify manage growth as it scaled up?
Spotify began with scrum but soon started to apply agile principles in the following manner:
1) Squads
2) Tribes
3) Chapter
4) Guild
Trio
6) Alliance
7) Chief Architect
Here’s a detailed explanation of each component.
Squads: The Basic Unit for development at Spotify is the team. A squad is similar to a scrum group and is designed to feel small, start-up-like. There can be multiple squads within an organization. Each squad is composed of 6-12 people.
Each squad is focused on a specific area. Each member of a squad is usually seated together. They have all the skills and tools necessary to design, develop and test products and then release them into production.
The squad is autonomous, self-organizing, and self-managing. Each squad is free to choose their own agile methodology. Some squads use Scrum sprints, others Kanban, and some mix scrum and Kanban. Squads may also use the Most viable product (MVP), to release earlier.
Each squad has a long term mission, such as building and improving the product. Each squad has an agile coach who helps them improve their work habits. The product owner is responsible for the vision of the feature area.
Retrospective and sprint planning meetings are not conducted by the Agile coach. Each squad has direct interactions and no blocking dependencies with other squads.
The majority of squads have a great workspace, including a desk area and a lounge area. There is also a “huddle” area. Nearly all of the walls are covered in whiteboards.
The Squads are encouraged spend 10% of their time on hack days. Hack days allow people to do whatever they like, often sharing their ideas with others.
Hack days are fun and can lead to product innovations.
A Squad’s high-level view:
Product owner – The product owner is a member of the squad who prioritizes the work and considers both tech and business aspects.
Agile coach – The team has an agile coach who helps them identify and overcome obstacles and continuously improves their process.
Influencing work – Each squad member has the ability to influence his/her own work, take part in planning and decide which tasks to tackle. Hack days can be a 10% time-consuming activity for every squad member.
Easy to release – The team can (and does!) make it easy! You can get stuff live with minimal hassle.
The team-friendly process – The squad takes ownership of the process and works to improve it.
Mission – Everyone knows and cares deeply about the mission of the squad, and stories in the backlog are connected to it.
Support for organizations – The squad knows who to call for help with problem-solving, both for technical and “soft” issues.
Pictorial representation