Spotify's Scaled Agile Model
Spotify Model is not exactly a model but an evolution of the internal practices of Spotify into a Scaled Agile Model and reflects the scaling both from technical and cultural perspectives. It is a people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network. It focusses on autonomy, communication, accountability, and quality.
The model was first spelled out in a blog article Scaling Agile @ Spotify by Henrik Kniberg and Anders Ivarsson. Unlike the other models which focusses on process, Spotify Model focusses on business and asks the organization to structure itself around the business.
Spotify Model has two team levels and three slices -
Each team is called a Squad. It consists of 6-12 team members focussing on one feature area. Each Squad is cross-functional, autonomous and has a unique mission. It is something like a Scrum Team and a mini-startup. It has an Agile Coach and a Product Owner for guidance and has the freedom to choose it's own Agile Methodology(Scrum/Kanban etc). Multiple Product Owners coordinate each other to fulfil the high level roadmap and the Product Owner maintains the Product Backlog to reflect the roadmap. A Squad is expected to deliver a MVP and improvise on that(Think it, build it, ship it, tweak it).
A Tribe is a group of Squads coordinating with each other on the same feature. Tribes generally contain 40-120 members. It is interesting to note that 120 is based on the Dunbar number 150 which is the maximum relations a person can have. Tribes act as incubators for new features and the Squads inside a Tribe are co-located. There is no specific Tribe level
"Scrum of Scrums" but it can be arranged on demand.
While Dependencies between Squads are not supposed to exist, any such identified dependency will have to be addressed soon. These can be at Squad level or at Tribe level.
Along with this, there are three team slices -A Chapter is a group of subject matter experts. They help keep Engineering standards in place in a discipline. Chapters are typically led by a Senior Technology Lead.
A Guild is a group of people with a common interest. While Chapters are limited to a Tribe, Guilds are across tribes and anyone interested can join it. A Guild doesn't have a lead but has a voluntary Guild Coordinator
Trio or TPD Trio is in essence is what which manages a tribe. This troika of Tribe Lead, Product Lead and Design Lead will ensure that there is continued coordination between the three perspectives.
An extreme case is an Alliance where multiple tribes(minimum three) are expected to work on the same feature.
Along with this, there is a System Owner who owns an independent piece of software and ensures that changes don't go out of control - it depends whether it is a single System Owner or a group of System Owners or a Dev-Ops pair of System Owners based on the criticality. A System Owner, per se, is not a separate role but a Squad or a Chapter member who takes a day off as System Owner Day to manage the System.
A Chief Architect looking into overarching design decisions is another optional role.
Spotify's Model is a traditional Matrix model which focusses more on delivery than on process. It follows the classic Professor and Entrepreneur Model(Mary and Tom Poppendieck) where the Product Owner is the Entrepreneur or the Product Champion and the Chapter Lead is the Professor or the Competency Lead. While one focusses on delivering quickly, the other focusses on delivering proper perfectly thereby creating a healthy tension.
Unlike the other Models, Spotify Model doesn't have an enterprise process. Any process, if at all, will be the best fit chosen by the Squad and because Squads are independent, they can have their own process. It's upto the Squad to figure out how to make the job done. While less formal process and ceremony and more self-management and autonomy are the major advantages of this model, it demands an organizational shift to work successfully.
Best Practices
10% of the effort is spent on "hack days" where people do whatever they want to generate new ideas.
A Squad maintains direct contact with the stakeholders and has no cross-dependencies with other Squads
A quarterly survey is performed at Squad level to assess the performance
- Effectiveness of the Product Owner and Agile Coach
- Capability to influence the work being done
- Easy to deploy
- Views on the Process which the Squad follows
- Squad Mission
- Organizational Support
But, as noted, Spotify’s Model is very hard to implement as this is not a proper model but a way of working which evolved with time. It is too chaotic at the onset and having a central command structure is really hard. Why does it work? A squad owns a piece of production functionality and is free to play with it at it’s heart’s content. But, business architectures are not that simple!! Even there, it’s hard to manage when a tribe has seven teams and each of the seven follow their own agile model. But, yes. If you can enforce that a tribe can have a single model(meaning a single large feature owner should have only one model), this may work. Else, it gets too chaotic to use. Besides that, everything else makes absolute sense - especially the guilds, chapters and even the System Owner.
References
Discover the Spotify model - Mark Cruth
Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds