Spotify is a success history. Originally an startup in Stockholm, now playing a key role in the music industry.
There are a lot of things that have been done at Spotify that we can use as a best practice to be implemented in modern companies. In this document, we will talk about how Spotify scaled Agile so it could be the project management methodology of choice.
Spotify is a company based in different locations worldwide with multiple development teams. Using Agile methodologies was a no brainer, so it was necessary as well to scale Agile in order to deal with the multi-team, multi-location challenge presented by this company.
Spotify’s method to scale Agile
The basic development unit at Spotify is the Squad.
- Is very similar to a Scrum team, with a product owner. They don’t have a leader, but the product owner can assign priorities to tasks. They also have access to Agile coaches when necessary. They have direct access to stakeholders.
- Product owners of different squads collaborate in order to maintain a high level product roadmap and remove dependencies between squads.
- They work together at the same location. Usually, they personalize a common space to work together.
- They have all the skills they need to design, develop, test and deploy a digital product by themselves. They are fully self-empowered.
- They can decide how to organize their work, using Scrum sprints, Kanban, or whatever they want.
- They all have an specific mission.
- They are encouraged to apply Lean Startup principles like MVP and validated learning.
- They spend around 10% of the time on ‘hack days’, just to promote learning and innovation.
A Tribe is a collection of squads that work in related areas.
- They are independent.
- Each tribe has a tribe lead who provides the best habitat for squads in this tribe.
- Squads in the same tribe share the same location.
- Tribes are designed to don’t have more that 100 members. As per the Dunbar number concept, people can’t have a social relationship with more than 100 people. That’s why tribes have a limited size.
- They setup get-togethers from time to time to show how each squad is doing.
- Dependencies between squads are removed at tribe level. For that, it’s important first of all to identify these dependencies:
A source of dependencies at many companies is friction between development and operations. Spotify has an interesting approach in order to fix this issue. Instead of having a single team in charge of operations, they have an operations team that provides guidelines and support to each squad so they can do their work in an independent way.
Until now, we’ve seen that there is a fair amount of autonomy at Spotify between different squads and tribes. That may lead to undesired situations, like a tester in squad A dealing with an issue already detected and fixed by another tester in squad B.
In this case, it would be great to have a common area to share knowledge between people in different squads.
The Chapter is a group of people having similar skills and working within the same general competency area, within the same tribe. For example, we can have a chapter of testers in tribe A.
- They meet on a regular basis to discuss their specific challenges.
- There is a chapter lead, which can be considered as the line manager of the chapter. But we want the chapter lead to be a regular member of a squad.
The Guild is similar to the Chapter, but in this case they span across different Tribes. A Guild is a community of interest, a group that wants to share knowledge.
A guild often includes all the chapters working in that area and their members. For example the testing guild includes all the testers in all testing chapters.
- Each guild has a guild coordinator.
What is the goal with this kind or organization?
The way Spotify is organized, it looks like a matrix organization. But it’s a matrix in which the vertical dimension is the “what” and the horizontal dimension is the “how”, as we can see here:
The point here is for everybody to easily know what to do and how to do it. That’s the key point that gives sense to this kind of organization.
And what about architecture?
Spotify has more than 100 different systems, and each one is completely independent. As everybody is basically free to make changes everywhere they want, there is a strong risk of conflict between different squads.
In order to avoid this situation, Spotify introduced the role of the System owner. Every system has one system owner (or, even better, two system owners for the same system).
The system owner is the “go to” person(s) for any technical or architectural issues related to that system. Usually a squad member or chapter lead with other day-to-day responsibilities, they only spend part of their time doing this job.
There is also the role of the Chief architect role, a person who coordinates work on high-level architectural issues that affect multiple systems.
Would it work for us?
That’s the million dollar question, and it doesn’t have an easy answer. There are a number of obstacles we need to sort out if we want to work the Spotify way:
- The setup of a squad (an independent group of people, self-empowered, working together at the same location) is not easy to achieve in modern IT-companies following the offshore-nearshore approach.
- The kind of access we need for stakeholders for this model to work as required is not easy to reach.
- There shouldn’t be any barriers between team members and system owners.
- We need a huge grip on architectural issues if we want the model to work as expected.
- Spending part of the time for innovation purposes is sometimes a very complicated thing.
- Dependency removal is almost mandatory for this model to work, and that’s not an easy task.
- The implementation of this kind of methodology might face some resistance in strongly hierarchical organizations.
The good thing about the Agile scaling method being used at Spotify is that is quite simple and easy to implement. Actually, way easier than other scaling methods many people considers nowadays, like SAFE, DAD or LESS.
The problem is that the kind of structure we need in a company to be able to work in this way is not always easy to achieve.
Let’s then consider this one as a good starting point, but we should never forget taking into account our specific situation when dealing with the issue of scaling Agile in a company.