Business Agility

Spotify: A Scrum@Scale Case Study

Spotify was “pretty much a Scrum company” from the start. With 2018 revenue of nearly $6bn and over 4,000 employees internationally, the company, founded in Sweden in 2006, has of course had many growing pains as they scaled Scrum to their current size.

By 2012, Spotify had successfully scaled Scrum to over 30 teams across three cities. At this point, the company had about 15m active users with 4m of those paying for their premium service (currently, in 2019, these numbers stand at 232m and 108m, respectively). Though Spotify had always been disruptive and a competition challenger, like any agile company, their teams discovered an increasing need to coordinate as the company grew.

Henrik Kniberg, Scrum at Scale trainer and storied mentor in agile and lean principles, cross-trained with Dr. Jeff Sutherland for years leading up to 2014. Together, this work helped Spotify organically scale their Scrum implementation to meet the growing organization’s needs. Small, cross-functional, and self-organizing teams encourage constant improvement, innovation, and continuous deployment in this Scrum at Scale case study

The Spotify model’s Scrum teams, called “Squads,” are designed to feel very much like a small start-up. They are co-located and have all the skills and resources needed to bring their product to release. Each Squad has a dedicated agile coach who provides training and support in addition to enabling teams to enhance and maintain a positive culture. 

Spotify’s Scrum teams, called Squads, include team members and a Product Owner
Squads, in turn, are organized into “Tribes,” which are, by the previous analogy, similar to a start-up incubator and what Scrum at Scale refers to as Scrum of Scrums. The Squads in a given Tribe all work in a similar feature. For instance, there is a Tribe working on Spotify’s music player, backend infrastructure, etc. 

Scrum at Scale emphasizes the importance of keeping teams small. Accordingly, the size of Spotify’s Tribes are determined by the so-called Dunbar Number—the theoretical upper limit to a social unit’s size where each individual can keep track of their relations to one another. Despite the autonomy of each Squad, dependencies between Squads are inevitable. To achieve cross-Squad coordination, Spotify uses an analog of Scrum at Scale’s scaled daily scrums for “on-demand” meetings as needed.

There are, of course, impediments to having 30 autonomous start-up-like Squads, such as the loss of an economy of scale. Consider for instance a situation where a tester on one Squad has encountered a problem that a tester on another Squad has solved in the previous week. If testers could get together across both Squads and Tribes; i.e., across Scrum teams and Scrums-of-Scrums (SoSs), such problems could be alleviated. For this reason, Spotify introduced “Chapters” and “Guilds” into their model. These are both great examples of cross-team collaboration, which is one of the twelve components of Scrum at Scale.

In Spotify’s Scrum at Scale implementation, Kniberg and Sutherland introduced cross-team collaboration and enabled Squads to be cross-functional.

Chapters are collections of Squad members from within a single Tribe with similar skills, competencies, and functions. Each Chapter within a Tribe meets regularly to facilitate cross-team collaboration and to discuss area-specific impediments for areas like testing, web development, or backend. Some Squads, of course, will have more than one Chapter specialist; and the basic unit of a Squad helps keep things grounded in product delivery.

The notion of a Guild captures a broader “communities of interest,” cutting across both Squads and Tribes. It is also yet another example of cross-team coordination. This broader community can help address issues and learning for topics that affect the organization as a whole, rather than just issues within a particular Tribe. So, while Chapters cut across Squads within a Tribe, Guilds collect together Chapters from multiple Tribes. Examples of Guilds include web development, testers, and agile coaches. And, while all members of the relevant Chapter are included in the associated Guild, any other team members who are interested may join. An example of Guild work might be an open space event held at one of Spotify’s locations to discuss challenges and solutions within their field.

While the Spotify model combines the Scrum at Scale approach with matrix-based organization, it diverges from the latter in important ways. For instance, in matrix-based organizations, similarly-skilled people are pooled into functional departments, assigned to projects based upon their department, and report to functional managers. The Spotify approach to Scrum at Scale gives much more weight to delivery. For example y-axis of the matrices’ dimension (vis a vis the Squad) is just a Scrum team. Team members are cross-functional and co-located. The matrices’ x-axis for Chapters and Guilds is primarily for sharing knowledge, tools, and skills.

Spotify’s Scrum at Scale implementation was tailored to the organization’s specific needs; the unique organization of Squads, Tribes, Chapters, and Guilds were helped their flexible approach.

Think of the Product Owner of the Squads along the y-axis as driving the product’s “what” and the Chapter Leads along the x-axis as driving the product’s “how.” As with Scrum itself, Scrum at Scale maintains the separation of concern and accountability between the “what” and the “how” as reflected in the distinction between the Scrum Master cycle and the Product Owner cycle. This conceived division of labor also corresponds to what Poppendieck calls the Professor and Entrepreneur model. The Product Owners are considered Entrepreneurs: they drive the fast pace of releases, respond to market conditions, and ensure appropriate prioritization. The Chapter Leads correspond to Professors: they maintain excellence in standards and practices, taking responsible for the product’s quality. There is a healthy tension between the PO’s tendency to push for speed and the Chapter Lead’s tendency toward thoroughness and technical excellence.

Anyone from any Squad is permitted to edit any system, which is necessary insofar as Squads are effectively feature teams and getting new features into production typically involves the editing of multiple systems. Empowering Squads to enter short feedback loops in this way ensures minimal decision latency. The latest CHAOS report suggests that decision latency is a leading indicator of project success or failure. This is also why Scrum at Scale has a PO on every team, thereby empowering teams to make decisions with minimal viable bureaucracy.

To mitigate the obvious architectural risk of having cross-Squad edits conflict, Spotify also employs System Owners for each system. Often, System Owners come in pairs. One person approaches architecture management from an operations perspective and the other from a developer’s perspective. These two System Owner roles can be seen, respectively, as another implementation of the division between the Scrum Master cycle and the Product Owner cycle.

The Scrum at Scale framework was iterated on by Sutherland based on real-world experience and feedback from companies like Spotify.
While the description above might make it sound as though Spotify has scaled Scrum in a fixed manner, it should be pointed out that flexibility is key. Indeed, the above structure including Squads, Tribes, Chapters, and Guilds is only an ongoing snapshot of the Spotify model from the first few years. This is precisely the reason why the Scrum at Scale framework is lightweight and context-agnostic; it should allow the implementation to evolve organically at a sustainable pace while maintaining continuous improvement. Today’s scaled solutions for fast growth can sometimes give birth to tomorrow’s problems. Maintaining simplicity in scaling Scrum provides a framework for keeping abreast of inevitable change.

At the core of every agile implementation, whether scaled or not, is a spirit of innovation and continuous technical development. To help create a culture of innovation in their teams, Spotify introduced the notion of Hack Days. Squad members have 10% of their time alloted to Hack Days, where they are encouraged to work on any project of their choosing, whether it’s a new useful product or more whimsical and fun. Not only does this initiative boost happiness, it also encourages refinement of technical expertise and, sometimes, important product innovations.

The Scrum@Scale framework is the brainchild of Dr. Jeff Sutherland, the co-creator of Scrum and the founder of Scrum, Inc.; it naturally extends the core Scrum framework and enables organizations to deliver hyper-productive results.