Spotify Model - Revision history

User at 14:21, 3 September 2021

2021-09-03T14:21:39Z

User at 14:09, 3 September 2021

2021-09-03T14:09:11Z

User at 13:43, 3 September 2021

2021-09-03T13:43:56Z

User at 13:39, 3 September 2021

2021-09-03T13:39:09Z

User at 13:35, 3 September 2021

2021-09-03T13:35:31Z

User at 13:31, 3 September 2021

2021-09-03T13:31:17Z

User at 13:21, 3 September 2021

2021-09-03T13:21:34Z

User: Created page with "'''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 Squad..."

2021-09-02T20:01:40Z

Created page with "'''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 Squad..."

New page

'''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.

== Benefits and Challenges<ref>Benefits and Challenges of the Spotify Model [https://productschool.com/blog/product-management-2/spotify-model-scaling-agile/ Product Scholl]</ref> ==

'''Benefits'''<br />
*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.

'''Challenges'''<br />
*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.

== Spotify Model Best Practices<ref>Spotify Model Best Practices [https://www.atlassian.com/agile/agile-at-scale/spotify Atlassian]</ref> ==
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.

@@ Line 64: / Line 64: @@
 *The Quarterly Survey in the Squads and handling dependencies within and across Tribes enables agility and [[Continuous Process Improvement (CPI)|continuous improvement]].
 *The Guilds help in improving the [[Organizational Culture|organizational culture[[ to better adapt to the technological advancements and provide competitive readiness.
@@ Line 97: / Line 105: @@
 == See Also ==
 *[[Agile Absorption]]
 *[[Agile Manifesto]]

@@ Line 29: / Line 29: @@
-*'''''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.
+*'''''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|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 [[Software Development|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.
@@ Line 38: / Line 38: @@
-*'''''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.
+*'''''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 Practice|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|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.
@@ Line 58: / Line 58: @@
 == Spotify as a “Scaling Agile Model”<ref>Spotify as a Scaling Agile Model [https://www.knowledgehut.com/blog/agile/spotify-model-agile Knowledgehut]</ref> ==
 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.
+*Spotify Model recognizes the need for a Network Structure within the [[Organization|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 Quarterly Survey in the Squads and handling dependencies within and across Tribes enables agility and [[Continuous Process Improvement (CPI)|continuous improvement]].
-*The Guilds help in improving the organizational culture to better adapt to the technological advancements and provide competitive readiness.
+*The Guilds help in improving the [[Organizational Culture|organizational culture[[ to better adapt to the technological advancements and provide competitive readiness.
@@ Line 73: / Line 73: @@
 '''Challenges'''<br />
-*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.
+*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 [[Enterprise Architecture|architecture]], [[Risk Mitigation|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.
@@ Line 82: / Line 82: @@
 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.
+If your development teams work in parallel, but legal or [[Marketing|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.
+It is worth adding that trying to layer the Tribe and Squads approach over a [[Hierarchical Organization|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.

@@ Line 1: / Line 1: @@
 == Definition of the Spotify Model ==
-'''The Spotify Model''' is a people-driven, autonomous [[Framework|framework]] for scaling [[Agile Methodology|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''' is a people-driven, autonomous [[Framework|framework]] for scaling [[Agile Methodology|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|Scrum]] team.
@@ Line 22: / Line 22: @@
 **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.
+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 [[Stakeholder|stakeholders]] to facilitate [[Communication|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.
+Squads are self-managed. As such, they are free to choose between any agile frameworks ([[Kanban]], [[SCRUM|sprints]], [[Minimum Viable Product (MVP)|MVP]]…) as they see fit. Similarly, scrum ceremonies are entirely optional. Giving teams this kind of flexibility requires agile tools.

@@ Line 94: / Line 94: @@
 *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.
 == References ==
 <references/>

@@ Line 26: / Line 26: @@
-[[File:Squads.png|400px|Squads]]
+[[File:Squads.png|300px|Squads]]
@@ Line 75: / Line 75: @@
 *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.

← Older revision		Revision as of 13:31, 3 September 2021
Line 4:		Line 4:

	[[File:The Spotify Model.png\|400px\|The Spotify Model]]		[[File:The Spotify Model.png\|400px\|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\|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 [[Organizational Structure\|structure an organization]] to enable agility.


Line 43:		Line 48:

	[[File:Guilds.png\|400px\|Guilds]]		[[File:Guilds.png\|400px\|Guilds]]
		+
		+
		+	'''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”<ref>Spotify as a Scaling Agile Model [https://www.knowledgehut.com/blog/agile/spotify-model-agile Knowledgehut]</ref> ==
		+	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 to better adapt to the technological advancements and provide competitive readiness.