As described in our prior posts (Insights, Backlog, Planning Poker, and Spike), the Research & Development team adopted a full Agile approach about 5 years ago. We try to continuously improve our process, and that’s why we recently attended a new Agile course. It’s a long journey from basic Agile principles to the most innovative ideas that a company can adopt in order to benefit from them.
As most of you probably already know, Spotify is the largest and most popular audio streaming subscription service in the world. A key part of Spotify’s success is driven by the company’s unique approach to organizing around traditional work roles to enhance team agility. Spotify’s team documented their experience, shared it with the world, and influenced the way many technology companies now organize their employees.
The Spotify model isn’t a framework since it represents Spotify’s view on scaling from both a technical and cultural perspective. It’s one example of organizing multiple teams in a product development organization, and it stresses the need for culture and networks.
They believe that to improve operational efficiency, you should give the teams autonomy and work on aligning them in order to create a worthwhile result.
The foundation of the Spotify Model is autonomy and trust. When there is trust, then there is ownership and accountability of the work done. Trust helps to create an environment where failure is taken as an opportunity to learn, innovate and change accordingly. This also uplifts individual morale and growth.
In order to manage their team and orchestrate the work, Spotify created a sort of “matrix” on which their employees are organized. I’d like to give you an overview of the key roles this matrix is based on.
The core concept is the Squad. It is similar to a scrum team of 6-12 people. A squad is autonomous, self-organizing, and self-managing. Each squad has a mission to accomplish, focusing on a feature area, and is free to choose an agile methodology. All squads always have an agile coach to help them improve their way of working. There is also a product owner who defines the vision for a new feature area.
Multiple squads that work on the related feature area make a Tribe. Each Tribe has a Tribe Lead who is responsible for helping coordinate across Squads and for encouraging collaboration. With multiple squads, there will always be dependencies. Dependencies are not necessarily bad – squads sometimes need to work together to build something really good. Nevertheless, their goal is to minimize dependencies that are blocking or slowing a squad down.
There is a downside to everything, and the potential downside to full autonomy is a loss of economies of scale. The tester in squad A may be fighting a problem that the tester in squad B solved last week. If all testers could get together, across squads and tribes, they could share knowledge and create tools for the benefit of all squads.
Chapters are the family that each specialist has, helping to keep engineering standards in place across a discipline. Chapters are typically led by a senior technology leader, who may also be the manager for the team members in that Chapter.
A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices. Anyone can join a Guild and they are completely voluntary.
A Trio is a combination of a Tribe Lead, product lead, and design lead. Each Tribe has a Trio in place to ensure there is continuous alignment between these three perspectives when working on feature areas.
A combination of three trios makes an Alliance. It is led by a product, design and a tribe lead.
We in the R&D team think that the Spotify model is a great source of inspiration. We are currently discussing if one or more concepts highlighted by this model can be used to improve the way we work together.
If I’ve intrigued you about any of these new concepts, I suggest you take a look at these videos that explain what life at Spotify is like: