Spotify Model

Revision as of 14:21, 3 September 2021 by User (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Definition of the Spotify Model

The Spotify Model is a people-driven, autonomous framework for scaling agile. The model emphasizes the importance of culture and network and is implemented through Squads, Tribes, Chapters, and Guilds. The foundation of the model is the squad and it acts like a Scrum team.

The Spotify Model

According to Spotify coach Henrik Kniberg, however, 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 stresses the need for culture and networks.

The model was introduced to the world in 2012, when Henrik Kniberg and Anders Ivarsson published the whitepaper Scaling Agile @ Spotify, which introduced the radically simple way Spotify approached agility. Since then, the Spotify model has generated a lot of buzz and become popular in the agile transformation space. Part of its appeal is that it focuses on organizing around work rather than following a specific set of practices. In traditional scaling frameworks, specific practices (e.g. daily standups) are how the framework is executed, whereas the Spotify model focuses on how businesses can structure an organization to enable agility.

Spotify Model - Elements and Roles[1]

This is the burning question: how does it all work? This agile model is meant to be both simple and playful while allowing for complex interactions between colleagues. Rather than just another agile framework, the Spotify agile model is an organizational structure based around different groups discussed below.

  • Squads: Squads are the most basic unit of the Spotify model. They can be compared to the agile team in other agile models, as they are autonomous teams composed of 6 to 12 people working together on a specific feature area. Each of these cross-functional team is assigned:
    • A mission, to guide their action and build their roadmap,
    • A Product Owner (PO), who communicates the project vision to the team and assigns priorities,
    • An agile coach, who provides support and guidance to the team to help improve their workflow and explain agile principles.

For more efficiency, their work is as self-contained as possible, in order for progress not to be hindered by tasks external to the squad. Moreover, the tribe is kept in close contact with all relevant stakeholders to facilitate communication. Squads are self-managed. As such, they are free to choose between any agile frameworks (Kanban, sprints, MVP…) as they see fit. Similarly, scrum ceremonies are entirely optional. Giving teams this kind of flexibility requires agile tools.


  • Tribes: Tribes are made up of multiple squads working together on related missions and features. Thus, they are larger groups that can comprise up to 150 members. They still retain a certain degree of autonomy but are placed under the authority of one or more tribe leads. Tribe leads can also be part of one of the squads present within the tribe. They are responsible for fostering teamwork and collaboration within the tribe and across the squads. One of the main aspects of their work consists in identifying and removing cross-tribe dependencies to make the development process smoother and more efficient. Squads from the same tribe work closely together, often in the same office. They also hold regular meetings to exchange ideas and review their work.
    • Trios: A trio refers to the tribe lead, the product lead and the design lead. Each tribe needs to be guided by a trio in order to keep the three approaches in mind.
    • Alliances: As the company grows, it may become necessary to think of ways to handle missions that would require the close collaboration of multiple tribes. Alliances refer to two or more (usually three) trios working together to align their respective tribes towards a common goal.


  • Chapters: Chapters are horizontal structures designed to regroup the specialists of a specific tool or area (a specific programming language for example) within a tribe. They act as backbones holding the squads together: they ensure best practices are established and followed by everyone working on a specific feature across the entire tribe. These standards make for faster development cycles and easier interoperability. Each chapter is headed by a chapter lead, who is usually a senior developer. The latter guides the other members of the chapter and helps them grow their skills to become even better specialists.


  • Guilds: Guilds are also transversal groups, but their scope is larger than chapters, as they may include people from different tribes, meaning its members can work across the entire organization. Chapters and guilds are largely related but operate at a different scale. They both function like communities designed to improve communication on topics of interest. Oftentimes, guilds include people from related chapters across multiple tribes (such as all the web developers, all the testers…). The purpose of guilds is to facilitate the exchange of solutions. A problem encountered by developers could already have been solved by a colleague from a different tribe: guilds allow this knowledge to be shared instead of wasting time. Guild members convene during workshops or hackathons, during which everyone gets an opportunity to further their knowledge. It’s important to note that guilds are open to anyone, unlike chapters which are reserved for specialists. This openness also encourages self-development and learning.


System-Wide Roles

  • System Owner: System Owners are responsible for keeping systems sane. As squads might need to make changes across different systems, their overall coherence may degrade if no one works behind the scenes to keep them up and running. System Owners are squad members or chapter leaders who dedicate part of their time to updating and fixing a system. For more complex systems, they might work in a Dev-Ops pair.
  • Chief Architect: The chief architect holds a key role: they oversee the done across multiple systems to guide squads and tribes during the development process. Though they provide advice as to what would be best from an architectural design perspective, the squad is still given the final say.

Spotify as a “Scaling Agile Model”[2]

Many of the foundational elements within the model become the backbone to scale agile in the organization adopting it.

  • Spotify Model recognizes the need for a Network Structure within the organization to make it nimble and agile.
  • The elements within the Spotify model help to establish Agile scaled to multiple teams spread across various locations and areas of work.
  • The Spotify Model recognizes self-empowerment and self-organization, and at the same time aligns the Squads within a Tribe to work in tandem, in order to create complete and usable software products.
  • The Chapters across Squads provide the environment for cross Squad collaboration.
  • The Quarterly Survey in the Squads and handling dependencies within and across Tribes enables agility and continuous improvement.
  • The Guilds help in improving the [[Organizational Culture|organizational culture[[ to better adapt to the technological advancements and provide competitive readiness.

SAFe Vs. Spotify[3]

The SAFe framework 4.5 is a lean-agile framework for working for several scrum teams together within the same structure. It offers a complete set of tools that range from scrum teams to portfolios. It also offers courses for its implementation and certifications to create coaches of the framework. SAFe offers a complete and detailed framework that reassures its interlocutors. But some experts see it as a framework much too detailed. SAFe tells you how to work, how to coordinate, how to train, and how to put it in place. Whether we like it or not, we must admit that it is incredibly complete. There is a small lean side to want to define everything and optimize. Overall SAFe is a heavy framework.

Spotify had set up a large-scale agile model which later on became very famous in the name of the Spotify model. It was Henrik Kniberg and Anders Ivarsson who communicated it in 2012. However, this model has become a reference and many companies are inspired by it from 2012. The Spotify model doesn’t want to be a big toolbox. The Spotify emphasizes the need to create many interactions to limit the silo side created by the squad. It will be essential to define how each team has to work in a general way or by leaving the autonomy to the teams at 100% usually Spotify model doesn’t detail anything at this level. Moreover, the Spotify model doesn’t bring any solution to manage the portfolio unlike SAFe. Spotify provides complete freedom and the team has to define everything. Overall Spotify is a lightweight framework.

There are no losers or winners, the SAFe framework and the Spotify model both have their advantages and disadvantages. The Spotify model offers some interesting concepts that you can use. However, it will be essential to have an agile coach to help you set up. Whereas SAFe offers training and certification to understand their framework and to create coaches who can guide the team on the framework. One side Spotify provides complete freedom to the team to decide their way of working and on the other side, SAFe will ask you to follow a set of recommendations for its implementation, which is much more reassuring by its strict framework side. The best option would be to use a mix of SAFe and Spotify model and it can produce a very interesting outcome when we blend the Spotify model with SAFe tools.

Benefits and Challenges[4]


  • Autonomy: The results across many companies speak for themselves; autonomous work is the future of successful agile product development. The main benefit of the Spotify model is that teams are empowered to make their own decisions and work in the way that best suits them. This encourages transparency, trust, collaboration, and experimentation, leading to better products.
  • Fewer bottlenecks and red tape: When teams run themselves and make their own decisions, they’re able to work faster and avoid time-wasting bottlenecks. The model encourages informal gathering and information sharing, without too much ceremony or formal process.


  • Risk to system architecture: Spotify has 100 distinct systems which form the overall product. When squads update one, they usually need to update several to implement the changes they’ve been working on. The risk here is that the architecture can go awry if everyone is only focusing on a small chunk of it at a time. Having a System Owner, someone (or a pair of someones) who owns the integrity of the architecture, mitigates this risk.
  • It won’t work for every company: The model looks fantastic from the outside, but choosing to implement it simply because it worked for Spotify is a mistake. The model fits the company culture, which is much more difficult to change than the framework you’re following. Rearranging the structure of your company is a big risk and a huge investment, and because the Spotify model was not designed to be copied by other companies, it may not be a good fit for yours.

Applying the Spotify Model to the Organization[5] == If you want to use the Spotify organizational model within your business, you should consider a few things that will be critical to success. By implementing only parts of the method or by trying to impose it on a different corporate culture, you will face difficulties while achieving the same level of success with it that Spotify had.

Remember that the organizational model assumes that engineering is doing development with Agile methodologies. Any Squad choosing to create with the help of the traditional Waterfall process would not be able to keep up with the rapidly changing teams around them. So, the critical requirement in making the model work well is that the whole company works with Agile practices and processes.

If your development teams work in parallel, but legal or marketing does not support an Agile approach, they will become a bottleneck that will slow down the overall company’s speed.

It is worth adding that trying to layer the Tribe and Squads approach over a traditional hierarchy would be problematic. You may gain some of the benefits of the Spotify model by creating full-stack teams in a traditional hierarchy, but you will definitely lose so many speed benefits.

Spotify Model Best Practices[6]

If you’re looking to enable a culture of trust, autonomy, and rapid learning, you can’t go wrong looking to the Spotify model for inspiration. If your organization is looking at the Spotify model as a means to help you approach agile at scale, the following is a list of best practices to keep in mind.

  • 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!

If you focus on these practices you’ll see positive impacts on how your organization collaborates and aligns, whether or not you use the Spotify model as a guide.

See Also


  1. How does the Spotify model work? Appvizer
  2. Spotify as a Scaling Agile Model Knowledgehut
  3. SAFe v/s Spotify PM Today
  4. Benefits and Challenges of the Spotify Model Product Scholl
  5. Should you try this model? Hygger
  6. Spotify Model Best Practices Atlassian