## The Spotify model - Agile

Many companies find it hard to scale Agile due to the various complexities that come with multiple teams, locations, time zones and different cultures. Over the past decade, many Scaling frameworks like SAFe, LESS, DAD have been introduced into the Agile world by various Agile practitioners and groups. This article is about one such scaling model called the “Spotify Model”. Origins of Spotify Model “Spotify” is a Sweden based music streaming company founded in 2006. The structure used by the company to scale agile across its various teams located in different locations came to be called as the Spotify Model. This model is becoming increasingly popular due to its flexibility and simplicity. Need for change in Organization Structure Today’s world is constantly changing due to social, political, and economic disruptions. The 2019-2020 COVID is a classic example of disruption in the entire world to the “business as usual”. To keep up with the disruption and competition, companies must be nimble and innovative to respond quickly and stay ahead of their peers. The hierarchical structures and organizational processes that worked well for decades are no longer enough to keep up with this fast-paced world. While traditional hierarchies and managerial processes are still very much required to run the show, the need of the hour is to also have an additional network structure operating in tandem with the traditional norms. The purpose of this network is to continually assess the business, the industry, and the organization, and react with greater agility, speed, and creativity than what has existed before.  There are so many examples around us where Start-up organizations thrive in the network structure and fail miserably when they have to scale, and cannot continue with traditional hierarchy and processes. In equal measure, around us are examples of Enterprise giants collapsing under the weight of the traditional hierarchy alone without the nimbleness and speed of the network structure.  Both the operating structures – the hierarchy and the network, are essential for today’s businesses to thrive. Kotter’s theory of establishing a dual operating system within an organization resonates heavily in the Spotify Model and compels us to draw parallels. In the Model we can see that there are innovative and thriving network structures and at the same time there is space to establish the traditional hierarchy as well. Spotify Model Squad: The Squad is the basic entity of the model which comprises the team that does the work. The Squad does not have a dedicated Squad lead but has a dedicated Product Owner.  The Product Owner tells the Squad “What” has to be done , prioritizes the work and maintains the backlog. Each Squad is self-organizing and can choose to follow Scrum, Kanban, XP or a hybrid of these. Squads are aligned to their mission, product strategy and short-term goals. Each Squad owns the release and delivery end to end. Typically, an infrastructure / DevOps Squad enables them to carry out smooth releases but does not do it for them. The Squad has access to an Agile Coach who runs retrospectives and Sprint Planning meetings. The coaches help the Squads to continuously improve. Tribe: A Tribe is a group of Squads that are related to each other by nature of the work being done by them. for e.g multiple Squads working together on the same product feature or closely related product features/ same product within a portfolio of different products.The number of people in a Tribe is recommended to be 100 in line with the Dunbar number. As per the Dunbar number, most people cannot maintain a social relationship with more than 150 people or so. All the Squads within a Tribe are co-located and physically able to interact in common areas dedicated for this purpose. There is a Tribe Lead who is responsible for creating a productive and an innovative environment for the Squads. The Tribe Lead can be part of a Squad as well.  Tribes meet often to showcase what they have been working on, what has been delivered and their learnings. The showcase could include the working software, new tools and techniques. Handling Dependencies One of the foremost challenges to resolve in a scaled agile environment are “conflicts and dependencies”. These can crop up during the development of a product among the Squads within a Tribe and also exist among Squads in other Tribes as well.   Dependencies could slow down or block the progress. Such dependencies are identified and are handled by reprioritization or through technical solutions. Sometimes innovative ideas could help remove the dependencies.  The end goal is to avoid dependencies between Tribes by making the Tribes self-organizing; and once that is achieved by having minimal dependencies among Squads within a Tribe. Survey for Continuous Improvement: A survey is done for all Squads at the end of every Quarter to understand the pain points and areas for improvement. For e.g multiple Squads having issues with the release process need urgent attention. One of the Squads not getting enough support from their Product Owner needs leadership intervention. Chapter: Certain disciplines/technological areas within the Tribe, like QA, Database Specialists, Front-end developers, Back-end developers, UX Specialists will benefit with regular discussions and interactions. People within these functions across multiple Squads and within the same Tribe constitute the Chapter. Constant communication within the Chapter members is encouraged. Each Chapter meets regularly to discuss their achievements and challenges in their respective areas of expertise e.g QA Chapter, UX Chapter, DB Chapter. There is a Chapter Lead who can guide the various members of the Chapter on “How” things can best be done. For e.g the QA Chapter lead can strategize the End-to-End Functional, Performance and Security Testing to be carried out for the new version of the product in an upcoming release. This will ensure the testers within all the Squads have a common well thrashed out testing strategy for the upcoming product release.  The Chapter lead can also be the line manager of the members in his Chapter, performing the traditional managerial responsibilities like people development, performance appraisals, career growth etc. The Chapter lead is also a member of one of the Squads in the Tribe, making him remain closer to ground realities.x All the Chapter leads within a Tribe typically could report to the Tribe lead, and the Tribe Lead performs all the managerial responsibilities for the Chapter Leads within his Tribe as well as the next level Squad members of his Tribe.  Guild : A Guild is like a “community of interest” cutting across Tribes throughout the Organization/ Business Unit.  Imagine an Enterprise that has three Tribes each located in three different locations. There could be QA Chapters for each Tribe with respect to the location. There is also a need for QA members of one Tribe to exchange and share processes and learnings with QA members of the other two Tribes. The Guild is an organic structure that serves this purpose.  The Guild cuts across the Tribes spread across the organization across locations. Knowledge, tools, and practices are shared. For e.g the QA Guild includes all the QA Chapter members and in addition can include other members who are interested.  Guilds usually are not focussed on a specific release or delivery but on their area of expertise in a generic way. They have mailing lists, publish newsletters and conduct unconferences once in a while.  Spotify as a “Scaling Agile Model” 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. Unique Benefits of the Model Spotify focusses on Agile Principles rather than mandating specific practices. Squads are autonomous to choose their own agile way of working. (Scrum/XP/Kanban/Scrumban etc. Not all Squads within a Tribe follow the same method) Specific Agile ceremonies and artifacts are not imposed on the Squad. Practices which work well with multiple Squads are automatically adopted by other Squads without the resistance that comes with standardization. This creates a balance of consistency across Squads along with the flexibility needed for autonomy. Though Squads are autonomous and loosely coupled they are tightly aligned by grouping them into Tribes. How Spotify is different from other Scaled Agile frameworks  While SAFe is a heavyweight scaled agile framework having many different flavours like Essential SAFe, Portfolio SAFe, etc, Spotify is more of a lightweight framework.  It might work very well for start-ups that are growing into medium Enterprises or for larger enterprises that are not ready yet for something as heavy as SAFe. The role of the Scrum Master is absent in Spotify, but the Squads have access to Servant Leaders in the form of Chapter and Tribe Leads and Agile Coaches. Conclusion  The Spotify Model has been a popular buzzword due to its unique nomenclature, flexibility and simplicity. It recommends the need for a community-based networking structure within the organization and focuses on the Agile Principles rather than Practices. It is a very unique and liberating Scaled Agile model and requires the practitioners to be extremely mindful and responsible while adopting it, so that it can be tailored for their specific organizational needs.

# The Spotify model - Agile

5K

Many companies find it hard to scale Agile due to the various complexities that come with multiple teams, locations, time zones and different cultures. Over the past decade, many Scaling frameworks like SAFe, LESS, DAD have been introduced into the Agile world by various Agile practitioners and groups. This article is about one such scaling model called the Spotify Model.

## Origins of Spotify Model

Spotify is a Sweden based music streaming company founded in 2006. The structure used by the company to scale agile across its various teams located in different locations came to be called as the Spotify Model. This model is becoming increasingly popular due to its flexibility and simplicity.

## Need for change in Organization Structure

Today’s world is constantly changing due to social, political, and economic disruptions. The 2019-2020 COVID is a classic example of disruption in the entire world to the “business as usual”.

To keep up with the disruption and competitioncompanies must be nimble and innovative to respond quickly and stay ahead of their peersThe hierarchical structures and organizational processes that worked well for decades are no longer enough to keep up with this fast-paced world.

While traditional hierarchies and managerial processes are still very much required to run the show, the need of the hour is to also have an additional network structure operating in tandem with the traditional norms. Thpurpose of this network is to continually assess the business, the industry, and the organization, and react with greater agility, speed, and creativity than what has existed before

There are so many examples around us where Start-up organizations thrive in the network structure and fail miserably when they have to scale, and cannot continue with traditional hierarchy and processes. In equal measure, around us are examples of Enterprise giants collapsing under the weight of the traditional hierarchy alone without the nimbleness and speed of the network structure.  Both the operating structures – the hierarchy and the network, are essential for today’s businesses to thrive.

Kotter’s theory of establishing a dual operating system within an organization resonates heavily in the Spotify Model and compels us to draw parallels. In the Model we can see that there are innovative and thriving network structures and at the same time there is space to establish the traditional hierarchy as well.

## Spotify Model

Squad: The Squad is the basic entity of the model which comprises the team that does the work. The Squad does not have a dedicated Squad lead but has a dedicated Product Owner.

The Product Owner tells the Squad “What” has to be done , prioritizes the work and maintains the backlog.

Each Squad is self-organizing and can choose to follow Scrum, Kanban, XP or a hybrid of these. Squads are aligned to their mission, product strategy and short-term goals. Each Squad owns the release and delivery end to end. Typically, an infrastructure / DevOps Squad enables them to carry out smooth releases but does not do it for them.

The Squad has access to an Agile Coach who runs retrospectives and Sprint Planning meetings. The coaches help the Squads to continuously improve.

Tribe: Tribe is a group of Squads that are related to each other by nature of the work being done by them. for e.g multiple Squads working together on the same product feature or closely related product features/ same product within a portfolio of different products.

The number of people in a Tribe is recommended to be 100 in line with the Dunbar number. As per the Dunbar number, most people cannot maintain a social relationship with more than 150 people or so. All the Squads within a Tribe are co-located and physically able to interact in common areas dedicated for this purpose.

There is a Tribe Lead who is responsible for creating a productive and an innovative environment for the Squads. The Tribe Lead can be part of a Squad as well.

Tribes meet often to showcase what they have been working on, what has been delivered and theilearnings. The showcase could include the working software, new tools and techniques.

### Handling Dependencies

One of the foremost challenges to resolve in a scaled agile environment are “conflicts and dependencies”. These can crop up during the development of a product among the Squads within a Tribe and also exist among Squads in other Tribes as well

Dependencies could slow down or block the progress. Such dependencies are identified and are handled by reprioritization or through technical solutions. Sometimes innovative ideas could help remove the dependencies.

The end goal is to avoid dependencies between Tribeby making the Tribeself-organizing; and once that is achieved by having minimal dependencies among Squads within a Tribe.

### Survey for Continuous Improvement:

A survey is done for all Squads at the end of every Quarter to understand the pain points and areas for improvement.

For e.g multiple Squads having issues with the release process need urgent attention. One of the Squads not getting enough support from their Product Owner needs leadership intervention.

ChapterCertain disciplines/technological areas within the Tribe, like QA, Database Specialists, Front-end developers, Back-end developers, UX Specialists will benefit with regular discussions and interactions. People within these functions across multiple Squads and within the same Tribe constitute the Chapter.

Constant communication within the Chapter members is encouraged. Each Chapter meets regularly to discuss their achievements and challenges in their respective areas of expertise e.g QA Chapter, UX Chapter, DB Chapter.

There is a Chapter Lead who can guide the various members of the Chapter on “How” things can best be done. For e.g the QA Chapter lead can strategize the End-to-End Functional, Performance and Security Testing to be carried out for the new version of the product in an upcoming release. This will ensure the testers within all the Squads have a common well thrashed out testing strategy for the upcoming product release.

The Chapter lead can also be the line manager of the members in his Chapterperforming the traditional managerial responsibilities like people development, performance appraisals, career growth etc. The Chapter lead is also a member of one of the Squads in the Tribe, making him remain closer to ground realities.x

All the Chapter leads within a Tribe typically could report to the Tribe lead, and the Tribe Lead performs all the managerial responsibilities for the Chapter Leads within his Tribe as well as the next level Squad members of his Tribe

Guild:Guild is like a “community of interest” cutting across Tribes throughout the Organization/ Business Unit

Imagine an Enterprise that has three Tribes each located in three different locations. There could be QA Chapters for each Tribe with respect to the location. There is also a need for QA members of one Tribe to exchange and share processes and learnings with QA members of the other two Tribes. The Guild is an organic structure that serves this purpose.

The Guild cuts across the Tribes spread across the organization across locations. Knowledge, tools, and practices are shared. For e.g the QA Guild includes all the QA Chapter members and in addition can include other members who are interested

Guilds usually are not focussed on a specific release or delivery but on their area of expertise in a generic way. They have mailing lists, publish newsletters and conduct unconferences once in a while

### Spotify as a “Scaling Agile Model”

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 Quarterly Survey in the Squads and handling dependencies within and across Tribeenables agility and continuous improvement.
• The Guilds help in improving the organizational culture to better adapt to the technological advancements and provide competitive readiness.

### Unique Benefits of the Model

• Spotify focusses on Agile Principles rather than mandating specific practices.
• Squads are autonomous to choose their own agile way of working. (Scrum/XP/Kanban/Scrumban etc. Not all Squads within a Tribe follow the same method)
• Specific Agile ceremonies and artifacts are not imposed on the Squad.
• Practices which work well with multiple Squads are automatically adopted by other Squads without the resistance that comes with standardization. This creates a balance of consistency across Squads along with the flexibility needed for autonomy.
• Though Squads are autonomous and loosely coupled they are tightly aligned by grouping them into Tribes.

## How Spotify is different from other Scaled Agile frameworks

While SAFe is a heavyweight scaled agile framework having many different flavours like Essential SAFe, Portfolio SAFe, etc, Spotify is more of lightweight framework.

It might work very well for start-ups that are growing into medium Enterprises or for larger enterprises that are not ready yet for something as heavy as SAFe.

The role of the Scrum Master is absent in Spotify, but the Squads have access to Servant Leaders in the form of Chapter and Tribe Leads and Agile Coaches.

## Conclusion

The Spotify Model has been popular buzzword due to its unique nomenclature, flexibility and simplicity. It recommends the need for a community-based networking structure within the organization and focuses on the Agile Principles rather than Practices. It is a very unique and liberating Scaled Agile model and requires the practitioners to be extremely mindful and responsible while adopting itso that it can be tailored for their specific organizational needs.

author

The author is an Agile Consultant working in the areas of process consultation and Agile coaching and transformation. She has been part of the software product development industry spanning field service, fleet management, telecom billing and network management.

## Join the Discussion

SPECIAL OFFER Upto 20% off on all courses
Enrol Now

## 12 Principles Behind the Agile Manifesto

5364
12 Principles Behind the Agile Manifesto

Long before Agile came into existence, almost ev... Read More

## Career Boost with CSM Certification

9562
Career Boost with CSM Certification

The ecosystem and landscape around every busines... Read More

## ScrumXP

This article briefly talks about popular Agile methodologies Scrum and XP, and how both these frameworks have been merged into ScrumXP—giving you the best of both worlds!  Scrum Scrum is the leading Agile framework practiced in the industry today. It follows an iterative approach where development cycles are 2 /3/4 weeks long. At the end of every iteration an incremental version of the product/solution is ready to be shipped.  Scrum prescribes events / ceremonies and specific roles within the team in order to achieve alignment and agility.  Sprint Ceremonies /Events Sprint Planning at the start of the Sprint Daily Stand-up during the Sprint Sprint Demo and Review to showcase the incremental working software developed in the iteration Sprint Retrospective at the end of the Sprint Scrum Roles Product Owner – Responsible for the product that is being developed. Is the representative of the Customer and Business. Scrum Master – Facilitates and orchestrates the various Scrum events, guides the team to align with Scrum values and principles. Team Member – Focusses on achieving Sprint goals, continuously strives to improve. Scrum Values  Courage - Every team member feels safe to fail and learn, to seek help, to say ‘no’ and question something that is going wrong. Commitment – Commits to Sprint goals as a team. Does not overcommit.  Focus - Aims to complete what is started and steer away from distractions and unprioritized/ "shoulder tap" work. Limits Work in Progress. Openness - Seeks and values feedback and opportunities to learn. Makes impediments, failures and learnings visible. Respect - Team collaborates and acknowledges the work and achievements of every member. Builds trust. Extreme Programming (XP) XP is one of the earliest ,most successful and proven Agile Methodologies.  It is very specific regarding the practices to be followed. XP is recommended to be used when the Customer is fully committed to deep involvement with the development team. XP teams rapidly produce software in short(mostly one week) iterations taking immediate feedback from the Customer. XP Values Communication – Communication within the team is as important as communication with the Customer Simplicity - Building a system that is easy to revise and maintain. Trying not to engineer too many and too much and only do what is required at that time. Feedback – Continuously striving to obtain feedback and acting on the feedback from Customer, Team and the Product. Courage – Courage to persevere and do the right thing. Respect – Respect for fellow team members and all stakeholders. XP Core Practices XP mandates certain core Engineering practices that distinguish this Agile methodology from the others. These practices take care of different aspects of agility and are interconnected at the same time.  They are grouped as below. Fine scale feedbackWhole TeamAll the contributors to a project – Developers, Testers, Analysts, Coaches etc who are part of the Project are part of the “Whole Team” that is centered around the Customer.Planning GameThe Customer presents the desired features and lays out an initial plan for the project. XP teams revise the release plan regularly.During Iteration Planning, the Customer presents the features desired for the next two weeks. XP teams build software in two-week “iterations”, delivering running, useful software at the end of each iteration.The total involvement by the Customer during Planning is an important practice of XP.Pair ProgrammingAll production code is touched by two team members. This ensures there is already another “reviewer” at work as the code is getting produced. This practice largely avoids bugs and coding errors.Test Driven DevelopmentTest before code is religiously practiced. Before a single line of code is written, a test for the same has to be written and run. This immediate and short feedback loop immensely helps to avoid waste, like bugs and wrong code.Customer TestsAcceptance Tests are defined by the Customer to validate if the features that are being introduced are fit to the purpose. The team automates these tests and builds a suite of such tests to run whenever required and to get immediate feedback from the system to check if all is well.Continuous processContinuous IntegrationContinuously integrating the code avoids the major problems that creep up when it is done  just before the release. Testing on a fully integrated system helps to detect critical bugs that might otherwise stay undetected for long.Design ImprovementDesign Improvements and Refactoring happens at healthy intervals to ensure system is cohesive and loosely coupled. This ensures the system can be easily extended with new features, scaled when required and maintained in good health.Small ReleasesWorking Software is delivered to Customer at the end of every iteration – either for actual use or evaluation and to obtain feedback.Shared understandingCoding Standards are practiced so that there can be collective ownership and any team member will be able to understand the code.Pair Programming and Coding Standards ensure that code is not owned by one single person and is the responsibility of the team.Design is kept simple and continuously improved and revised to cater to the current functional demands. Design is not done up-front but done at regular intervals.XP teams use a common system of names to ensure a common understanding of the system.Programmer welfareSustainable PaceXP ensures the team members work at a pace that can be carried out for a very long time.  The system avoids situations where the team members are left wanting for work at times and then have to scramble to finish deadlines.Scrum and XP – What is common and different. Scrum and XP are two popular Agile Methodologies having the same larger goal of delivering to the customer incrementally and iteratively. Both the methodologies lay great importance to customer centricity, feedback mechanisms, continuous improvement and building sustainable empowered teams.  There are few differences in the implementing mechanisms of these methodologies.  Iteration Duration: Scrum Iterations last for 2 /3/ 4 weeks. XP iterations are usually very short – one week long or at the most 2 weeks. Role of the Customer: XP and Scrum have Release Planning and Iteration Planning sessions. But unlike Scrum, in XP the Customer drives the planning and schedules the Release.  The Customer continuously interacts directly with the Teams in XP, while in Scrum the Product Owner represents the Customer and Business. The XP teams ensure to deliver a working bug free system at the end of every iteration. Customer chooses to evaluate and provide feedback or Release to the end users. Scrum teams deliver working software at the end of every iteration. The Product Owner with the input from teams decides on the right time for General Availability (GA) Release depending on the Market Readiness, Customer input etc. Practices: Scrum recommends using Engineering Best Practices like TDD, Pair Programming, Code Refactoring etc. but XP takes it to another level by mandating these Engineering Practices. Scrum recommends that items planned within a Sprint are unchanged until the end, but in XP, teams accommodate a sudden change of priority even during the iteration, by swapping items if work has not started on it. Roles: Scrum has dedicated Scrum Ceremonies whereas XP does not prescribe it per se. Scrum has a dedicated Scrum Master who facilitates these events, but XP does not have a Scrum Master.  XP teams get guidance from Agile Coaches.  ScrumXP- Using the best of Scrum and XP Practices When there are two great practices, there is always a tendency to combine both and get the best of both the worlds. “Lean-Agile”, “Scrumban”, “ScrumXP” are some examples of hybrid terms that have become increasing popular by combining two philosophies (e.g Lean and Agile ) or two methodologies (e.g Scrum and Kanban / Scrum and XP). ScrumXP is a hybrid practice making the most of both Scrum and XP. XP has laid out some very effective Engineering practices that teams practicing Scrum can greatly benefit from.  Many teams practice Scrum as their process framework and include the very effective and efficient core Engineering XP Practices in their way of working. This gives rise to the highly productive ScrumXP hybrid model of working. Mostly the ScrumXP teams retain the Scrum Master and Product Owner roles within their teams to take care of the required orchestration and facilitation. ScrumXP and SAFe “Team and Technical Agility” is one of the key competencies of SAFe. By following  ScrumXP the SAFe teams take care of the team Agility through Scrum Practices and Technical Agility through XP Practices.  The robust Engineering practices of XP ensures the product being built is of very high quality, easily extendable, maintainable and sustainable. In conclusion, ScrumXP provides the best of both worlds. Teams can begin with Scrum and continuously improve by including the robust core XP Engineering practices like TDD, pair programming, code refactoring etc— not because it is mandated but because they find it effective. Although, interaction with the Customer is through a Product Owner, the Scrum teams can borrow the Customer Centric approach of XP to remain aligned with Customer expectations.
5365
ScrumXP