Scaling Agile | Spotify

Editor's Notes

1. Squads Similar to a scrum team, Squads are cross-functional, autonomous teams (typically 6-12 individuals) that focus on one feature area. Each Squad has a unique mission that guides the work they do, an agile coach for support, and a product owner for guidance. Squads determine which agile methodology/framework will be used.
2. Tribes When multiple Squads coordinate within each other on the same feature area, they form a Tribe. Tribes help build alignment across Squads and typically consist of 40 - 150 people in order to maintain alignment (leveraging what we call Dunbar's Number). Each Tribe has a Tribe Lead who is responsible for helping coordinate across Squads and for encouraging collaboration.
3. Chapter Even though Squads are autonomous, it’s important that specialists (e.g. Javascript Developer, DBAs) align on best practices. 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 lead, who may also be the manager for the team members in that Chapter.
4. Guild Team members who are passionate about a topic can form a Guild, which essentially is a community of interest. Anyone can join a Guild and they are completely voluntary. Whereas Chapters belong to a Tribe, Guilds can cross different Tribes. There is no formal leader of a Guild. Rather, someone raises their hand to be the Guild Coordinator and help bring people together.
5. Spotify technology is highly service-oriented. We have over 100 distinct systems, and each can be maintained and deployed separately. This includes backend services such as playlist management or search or payment, and clients such as the iPad player, and specific components such as the radio, or the “what’s new” section of the music player. Technically, anyone is allowed to edit any system. Since the squads are effectively feature teams, they normally need to update multiple systems to get a new feature into production. The risk with this model is that the architecture of a system gets messed up if nobody focuses on the integrity of the system as a whole. To mitigate this risk, we have a role called “System Owner”. All systems have a system owner, or a pair of system owners (we encourage pairing). For operationally critical systems, the System Owner is a Dev-Ops pair – that is, one person with a developer perspective and one person with an operations perspective. The system owner is the “go to” person(s) for any technical or architectural issues related to that system. He is a coordinator and guides people who code in that system to ensure that they don’t stumble over each other. He focuses on things like quality, documentation, technical debt, stability, scalability, and release process. The System Owner is not a bottleneck or ivory tower architect. He does not personally have to make all decisions, or write all code, or do all releases. He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership. However, from time to time he will take a “system owner day” and do housekeeping work on that system. Normally we try to keep this system ownership to less than a tenth of a person’s time, but it varies a lot between systems of course. We also have a chief architect role, a person who coordinates work on high-level architectural issues that cut across multiple systems. He reviews development of new systems to make sure they avoid common mistakes, and that they are aligned with our architectural vision. The feedback is always just suggestions and input - the decision for the final design of the system still lies with the squad building it.
6. https://www.atlassian.com/agile/agile-at-scale/spotify The Spotify model is centered around simplicity. When Spotify began organizing around their work, they identified a handful of important elements on how people and teams should be structured. Trio The Trio (aka TPD 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 features areas. Alliance As organizations scale, sometimes multiple Tribes need to closely work together to accomplish a goal. Alliances are a combination of Tribe Trios (typically three or more) that work together to help their Tribes collaborate on a goal that is bigger than any one Tribe. That’s it. There are not a lot of practices that need to be followed or ceremonies that need to happen. Squads may have ceremonies like sprint planning and retrospectives, but the focus of the Spotify model is on how teams organize around work. It’s up to Squads to figure out the best way to get the job done.
7. Less formal process and ceremony The Spotify model focuses on organizing around work and not necessarily processes and ceremonies. This gives an organization greater flexibility when it comes to how Squads work. Instead of requiring Squads to change how they do their work (“you must do scrum”), it focuses on aligning them with each other and driving towards individual team outcomes. More self-management and autonomy The Spotify model encourages autonomy and creativity by trusting people to complete the work they are doing in the way they see fit. Do you need to ship software? That’s up to the Squad. Do you need to change direction? That’s also up to the Squad. The Spotify model focuses on decentralizing decision making and transferring that responsibility to Squads, Tribes, Chapters, and Guilds. “Control leads to compliance; autonomy leads to engagement.” - Dan Pink, Author, “Drive: The Surprising Truth About What Motivates Us” The Spotify model can offer increased transparency across the work being done and grow a more experimentation-based approach to problem solving in a high trust environment. All this can lead to things like better products, happier customers, and more engaged employees. However, not everyone will experience these outcomes.
8. The Spotify model was based on one organization's way of working. Many organizations desire the same benefits of the Spotify model, so they attempt to emulate what Spotify did. Some organizations experienced more success than others, but it’s likely no organization experienced the same success as Spotify. The reason? Like any way of working, an organization's current culture and structure need to be taken into account. The model is simple, but the environment it's implemented in is complex. Unfortunately, many organizations try to copy the Spotify model. To some, it may seem like a simple matrix organizational structure where people report to a functional area (Chapter), but work with a cross-functional team (Squad). However, it’s more complex than that. Although it may look like a matrix organization, the key cultural elements of the model need to be in place to allow the structure to thrive, such as trust and autonomy. If an organization doesn’t shift its behaviors (and ultimately its culture), the benefits of the Spotify model will never be realized. If you simply rename teams to Squads, you’re just putting lipstick on a pig. Wise executives tailor their approach to fit the complexity of the circumstances they face.   - Dave Snowden, Management Consultant
9. Don’t copy the model Seek to understand the structure, practices, and mindset behind Spotify’s approach. With that understanding, tweak the aspects of the model to fit your own environment. Your goal is not to be Spotify, but to leverage their model to improve how your organization works together. Autonomy and trust is key Spotify gave as much autonomy as possible to their people in order to help them pivot quickly. Allowing teams to pick their own development tools and modify another team's code are just some examples. Within your organization, determine if there are decisions that can be pushed to the teams instead of being mandated by parts of the organization that are disconnected from the day-to-day work. Transparency with community Spotify’s success is credited to their focus on building community and transparency around their work. Establish your first Guild around the Spotify model adoption and encourage participation from everyone in the organization. Build trust by creating transparent, inclusive ways to gather feedback, and gain alignment on how your organization wants to work in the future. Encourage mistakes You will fall down and stumble in this journey. But that’s okay. Improvement involves experimenting and learning from both our successes and failures. Spotify went through many iterations before they attained the model we know today, and have since continued to experiment to constantly look for new ways to improve the way they work. Encourage the same within your organization!