The Success of the: Tribe Model (Spotify model) Management for Scaling Agile

The Tribe Model Management is part of an agile scaling strategy that believes that smaller teams produce better results. It has helped Spotify and other organizations increase innovation and productivity by focusing on autonomy, communication, accountability, and quality.

The Spotify model was first introduced by Henrik Kniberg and Anders Ivarsson in 2012 when they published the whitepaper Scaling Agile @ Spotify, which introduced the radically simple way Spotify approached agility.

Characteristics of this approach involve:

• Encourages innovation, collaboration, autonomy and productivity.
• Using a unique organization system that features Squads, Tribes, Chapters, and Guilds.
• Focuses on decentralizing decision making and transferring that responsibility to Squads, Tribes, Chapters, and Guilds.

Teams are broken down into what they call Squads. A Squad is a cross functional team, like a Scrum Team but with a start-up and autonomous feeling consisted of up to 8 people.

Some use Scrum sprints, some use Kanban. Also they are encouraged to apply Lean Startup principles such as MVP (minimum viable product) and validated learning. MVP means releasing early and often, and validated learning means using metrics and A/B testing to find out what really works and what doesn’t. The purpose of both ideas is to optimize costs and waste.

A squad doesn’t have a formally appointed squad leader, but it does have a product owner while each product owner is responsible for maintaining a matching product backlog for their squad.

Other Characteristics of Squads:

• Squads are self-organizing and collocated.
• They work together to achieve a long-term mission.
• They are self organizing autonomous teams with end to end responsibilities from: design, deployment, operations, maintenance etc.

At Spotify, a Squad may be in charge of a task such as improving the app’s usability for Android, improving the Spotify radio experience, or providing payment solutions. Just like a Scrum Team, the Squad doesn’t have a formal leader, but they do have a Product Owner. Product Owners collaborate with one another to maintain a roadmap to track Spotify’s progress as a whole.

Each team also has access to an Agile coach to encourage continuous improvements.

Tribes are collections of squads that work in a specific area (for example and are meant to have less than 100 people.

The tribe can be seen as the “incubator” for the squad mini-startups. Each tribe has a tribe lead who is responsible for providing the best possible habitat for the squads within that tribe. The squads in a tribe are all physically in the same office, normally right next to each other, and the lounge areas nearby promote collaboration between the squads.

But… there is a potential downside to full autonomy of squads. This is a loss of economies of scale and knowledge sharing.

For example an engineer in squad A may be wrestling with a problem that the engineer in squad B solved last week. If all engineers could get together, across squads and tribes, they could share knowledge and create tools for the benefit of all squads. If each squad was fully autonomous and had no communication with other squads, then what is the point of having a company?

That’s why we have Chapters and Guilds. This is the glue that keeps the company together.

Chapters are small groups of people across a tribe that have similar skills and work in the same general competency area. For example all engineers from different squads and tribes belong to chapters.

Guilds are the largest group, comprised of people across the organization who want to share knowledge, tools, code, and practices.

A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices. Chapters are always local to a Tribe, while a guild usually cuts across the whole organization.

How to develop the Squads?

• Empower those teams and give them the authority to trial and error and fail sometimes
• Give them space to operate and reduce the bureaucratic overhead. For example weekly status reports might make them feel less autonomous and productive.
• Have transparent communication
• Encourage mistakes

Which other Agile Frameworks should I use?

KanBan

Key Point: Visualizes workflow stages

Advantage: Easy to implement

Disadvantage: May lack structured roles.

Suitable Projects: Projects with fluctuating priorities.

Scrum

Key Point: Employs time-boxed iterations (Sprints).Defines Roles (Product Owner, Scrum Master, Development Team)

Advantage: Promotes transparency & Facilitates collaboration.

Disadvantage: Framework may feel restrictive. Requires dedicated Scrum. Master & Product Owner Roles.

Suitable Projects: Complex Software development projects

Extreme Programming (XP)

Key Point: Focuses on technical excellence: Pair Programming.

Advantage: Enhances software quality.

Disadvantage: Intense Focus on technical practices which might overshadow other project aspects.

Suitable Projects: Projects with rapidly changing requirements. Critical software applications.

Lean Software Development

Key Point: Focused on waste elimination. Uses MVP.

Advantage: Minimizes Project delays.

Disadvantage: Focuses heavily on empirical data and KPIs. Might require mindset shifts.

Suitable Projects: Projects with limited resources.

1. https://www.atlassian.com/agile/kanban/kanban-vs-scrum
2. https://www.altexsoft.com/blog/extreme-programming-values-principles-and-practices/
3. https://medium.com/amateur-book-reviews/book-review-lean-software-development-an-agile-toolkit-by-mary-poppendieck-and-tom-poppendieck-d7a65cb4d274
4. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
5. https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/