Get certified - Transform your world of work today


Scaling Agile Using Spotify's Framework

24 December 2015

Agile today is a widely accepted methodology, fast transforming the way software is made. But Agile in its traditional form still has a few grey areas:
  • How do we scale up Agile from team level to program/portfolio/enterprise level?
  • What would be Agile metrics at the program/ portfolio/ enterprise level?
  • How do we minimize handoffs between teams, delivering value early to the customer?
  • How do we get employee and customer delight using innovative Agile frameworks?
If you want to find answers to these and how Tech Mahindra and our client (a large banking and insurance provider in Australia and New Zealand) use Spotify's framework for scaling Agile to realize those objectives, then read on. Spotify is an organization that operates under a true Agile culture. Henrik Kniberg and Anders Ivarsson wrote the whitepaper Scaling Agile @ Spotify, which has inspired many companies to follow their organizational model.


Agile, in its plain vanilla form, is practiced widely. However, the focus is still at the team level. Some challenges include:
  • Handoff between teams. Operation teams are constantly in conflict with development teams because of lack of knowledge transfer during the handoff to production.
  • Teams lack holistic skills to realize an idea from concept to cash, leading to conflict of interest and lack of ownership. This results in multiple management layers and funding hassles.
  • Although the Agile focus is at the team level, there is no strategy for scaling it to a program, portfolio, and an enterprise level.
To address these challenges, Tech Mahindra and Suncorp Group took a hard look at Spotify's Agile scaling framework.

Spotify's Agile scaling uses cross-functional teams with T-shaped skills that realize value from concept to cash and that can also build and maintain software or products. It also addresses how to scale up these autonomous cross-functional teams to a program or portfolio level to address some of the challenges. It further addresses the downside of having autonomous teams by having horizontal knowledge-sharing forums.

In a nutshell, Spotify's scaling provides dual benefits of autonomous economies and economies of scale.


The customer aims to achieve the following:
  • Build teams that develop, own, and maintain software or products.
  • Minimize handoff between teams.
  • Bring work to teams rather than forming transient teams around projects.
  • Fund release trains rather than projects, thus bringing value early into the life cycle.
  • Create an innovative environment where it is OK to fail at a legitimate risk taken, but the goal is to fail fast to minimize the impact on finances and teams.
  • Improve employee productivity and satisfaction with effective use of cross skills.

Agile without Spotify's scaling

Development teams and operations teams are not colocated. This results in a lack of synergy between the development teams and the operation teams over project handoffs.

Agile with Spotify's scaling

Visualize development teams as Squads

Perform the following tasks to visualize development teams as Squads:
  • Identify the skills (work types) that development teams need to realize requirements from concept to cash.
  • Identify the dependencies of development teams on other teams.
  • Perform a skill matrix baseline for development teams and make a T-shaped road map or cross-skills road map.
The development teams now can realize and maintain requirements from concept to cash. An operations team continues to be available for specialized support, which also creates self-service for development teams.

Visualize line-of-business portfolios as Tribes

Perform the following tasks to visualize line-of-business portfolios as Tribes:
  • Link all Squads that cater to a line of business into a Tribe.
  • Ensure that the Tribe has a leader who is a thought leader for the line of business.
  • Ensure that the Tribe leader provides the best habitat for Squads to perform and excel.
  • The Tribe leader works with the technical architect to ensure that an architectural runway is visualized for Squads.
  • Funding ideally happens at the Tribe level, not at the project level, to release trains so that work is brought to the Squads rather than forming teams around projects.
  • Persistent Squads encourage gradual buildup of domain knowledge and synergy, thus fostering high-performing packs.

Visualize knowledge-sharing forums as Chapters and Guilds

Squads and Tribes are more or less fully autonomous. But what we witness in full economies is loss of economies of scale or knowledge sharing. Therefore, form horizontal Chapters along technology or practices (such as testing). This formation translates into Guilds at an enterprise level, ensuring that knowledge sharing continues in spite of the autonomous teams. This is an amalgamation of new-world autonomous teams with old-world specialized teams.

Resource estimate

Spotify's scaling is more about scaling skills of existing resources in a T-shape model. The only cost associated with the scaling is training and cross-skills, which is on the job and in the classroom.
In essence, development teams can do operation support when needed while retaining their core development skills, and the operation support team can do core development when needed while retaining their core support skills. Such an amalgamated team is called a Squad. A team with T-shape skills doing work from concept to cash and one that also maintains products built is a Squad.

Each Squad will have a product owner, ScrumMaster, and T-shaped team. A collection of autonomous Squads aligning to a line of business is a Tribe.

A Tribe can be visualized as an incubator for mini start-ups. The size of a Tribe is typically not more than 100 people (based on the Dunbar number) because a bigger group leads to restrictive rules, bureaucracy, politics, and unnecessary management layers. Tribes hold a regular gathering in which each Squad showcases what it's doing, and everyone learns from each other.

Squads, as autonomous units, have a flip side. Full economies are a loss of economies of scale. For example, a tester in Squad A could have solved a problem recently that a tester in Squad B could be struggling with.

A Chapter is a horizontal slice across Squads within a Tribe. They have similar skills, work within the same general competency area, and within the same Tribe. A Guild is an enterprise-level Chapter.

Measurable impact

In our context, we had visualized our lines of business, such as insurance, banking, customer, and corporate, as Tribes with autonomous Squads for end-to-end delivery, while Chapters and Guilds retained knowledge in spite of autonomous Squads or Tribes.

The following are examples of metrics used to measure Squads, Tribes, and the enterprise.

Squad-level metrics


Lean and Agile Maturity Assessment (LAMA)

Tribe-level metrics


Enterprise-level metrics


As an organization, we used these metrics more than a year and observed the following results:
  • Minimized the handoff between teams, realizing a huge reduction in knowledge transfer.
  • Increased employee satisfaction because employees had the opportunity to widen their technology horizon.
  • Teams and portfolios aligned to a line of business, making it a robust entrepreneurial model.
  • Chapter and Guilds aligned with the knowledge base, making it a robust knowledge model.

Why the Tech Mahindra STAR Award recognized Suncorp

Spotify's scaling in Agile is an innovative, people-driven, and loosely coupled framework for scaling Agile. Although there are more rigid, process-driven, hierarchical frameworks, Spotify enters into this space as fresh air.

We have used Spotify's model for scaling in Agile to integrate development and operation teams, thus building synergy with a latent endeavor to "build product, maintain products" as an innovative approach to DevOps.

The cost involved in implementing the Spotify scaling framework is minimal; it is all about reusing and rejuvenating existing resources, with training and on-the-job collaboration, creating a win-win for both the employee and the company.

Spotify's scaling does not recommend additional roles or a hierarchical process; therefore, it reduces costs and fosters innovation. Spotify also redefines the way funding is done in that it funds release trains at the Tribe level rather than with transient projects.

The basic crux of Spotify's scaling is that teams become "brilliant at Agile basics," which both Tech Mahindra as an organization and our customer drive by using Agility Assessment.

Profile of key team

  • Operating domain: Banking and Insurance
  • Operating technologies: Business Intelligence technologies (IBM® Netezza, IBM® Cognos, Tableau®, IBM® InfoSphere Change Data Capture, IBM® InfoSphere DataStage, etc.)
  • Continuous integration: Jenkins, Stash
  • Automation tools: Tricentis Tosca Testsuite


  • Total associates (distributed across India and Australia): 200 plus
  • Total iteration managers (ScrumMasters) : 8
  • Total Certified Scrum Masters® (CSM®): 6
  • Total Scaled Agilists (SA): 2

Agile Infrastructure

  • Seating
  • Collaboration Tools – Lync TVs and video conference
  • Dedicated Agile coach
  • Overlapping shift hours
This paper was nominated in India Agile Awards – Agile Project of the Year 2015 By KPMG/ Unicom.


Henrik Kniberg and Anders Ivarsson. Scaling Agile @ Spotify with Tribes, Squads, Chapters, and Guilds. 2012.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (4 ratings)


Markus Gärtner, CST,CSP,CSD,CSM,CSPO,REP, 12/24/2015 4:15:09 AM
Please note that there is no such thing as a Spotify framework. In fact, the Spotify folks don't think they invented a framework. Rather they describe how they found a way that works for them.
Robert Day, CSM, 1/4/2016 9:40:57 AM
Ah! Forward to the future via 1970s-style matrix management! Not that I think there's anything wrong with that model; but isn't it funny that what goes around, comes around...
Deepak Kumar Rout, CSM,CSPO, 6/7/2016 2:34:58 PM
I agree with Markus;
Anonymous, 10/17/2016 11:44:46 PM
Isn't all of this a flavor of DAD or SAFe which are more formal tried and tested way by many orgs than just calling it a framework, created by one Organisation?

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up