Kendis is a digital solution for PI, Tribe and Big room Planning that works on top of Jira and Azure Boards.
Spotify has become a popular music player well known for providing original and a limitless collection of music content. It was launched in 2008 and has now become a large company with nearly 1600 employees. They owe their success to their deeply rooted agile methodologies and the utilization of the Agile Scaling in their own way. This method is called the Spotify Tribe.
When the company was started with fewer employees, the teams used scrum. Once they started to grow, it was time to change by scaling. They now have 30 agile teams that are spread over 4 cities in 3 different time zones.
Adapting a unique Agile Scaling Method has not only made them achieve their goals quicker but also brought a shift in the mindsets of the people in it. This article describes the structure and the benefits of the Spotify Tribe.
The Spotify Tribe Engineering Model
The constituents of this engineering model are:
- Squads
- Tribes
- Chapter
- Guild
- Trio
- Alliance
- Chief Architect
1. Squads
Similar to scrum teams, Spotify has squads. In an organisation, there can be multiple squads consisting of 6-12 people each dedicated to work on one feature area. A squad is autonomous, self-organizing and self-managing. Each squad has a mission to accomplish and is free to choose an agile methodology. Squads may follow KANBAN, scrum sprints, xp, or a mix of these to carry out their duties. In order to release early and often, squads apply the Most Viable Product (MVP) technique.
Squads have an Agile Coach that help improve their way of working. There is a Product Owner who defines the vision of the feature area. The agile coach conducts retrospectives while sprint planning meetings are kept optional. Each squad has direct contact with stakeholders.
Dev and ops work in such a way that the operations do not interfere with the work of the developers. Rather the operations pave the way for the developers to release the work for themselves. This is done by creating an environment such as building an infrastructure and the support to let the developers launch their work. Face to face communication is encouraged over documentation. Operations is a separate squad to help other dev squads.
2. Tribes
Multiple squads that work on the related feature area makes a tribe. A tribe may consist of 40-150 people but ideally, a tribe should have max. 100 individuals. A tribe has a tribe lead responsible for creating a productive and an innovative environment for the squads. The tribe lead can be part of a squad as well.
3. Chapter
At the horizontal level of the functional organization, there are chapters which are also known as the specialists. A chapter consists of individuals from different squads to be grouped into one and formed within a tribe. A chapter lead is also a line manager of the chapter members and support them in their personal growth and specific challenges.
4. Guild
An informal group constituted of people from different tribes, who have a common interest, form a guild. A person from any squad, chapter or tribe can be a part of a guild.
The purpose of having a chapter and a guild are the same; ensure transparency by solving problems and keeping the teams aligned and focused. For example, there is a tester from squad A who is struggling with a problem. There is another tester in squad B who has easily solved the same problem. If both are in the same chapter, they can share their problem and find a solution.
If they are in different chapters, then they would have a guild of testers where they can share their knowledge and help each other out.
The chapter lead has weekly meetings in which all the chapter members present upcoming issues and discuss a solution. Guild workshops like hackathon have been a famous activity for guild members.
5. Trio
A trio is formed when for every tribe there is a design, product area and a tribe lead.
6. Alliance
A combination of three trios makes an alliance. It is led by a product, design and a tribe lead.
7. Chief Architect
Lastly, a crucial member of organisation is the chief architect who defines architectural vision, guides in designs and deals with the system architecture dependency issues. To keep track of architecture issues, each system has a system owner who handles the dependencies of the architecture and keeps check of the frequent release delivery of each system. To mitigate any risks with the architecture, a system owner’s responsibilities are divided into dev and ops. These partial responsibilities can be handled by any member of a squad.
Benefits of the Spotify Engineering Method
The foundation of the Spotify Tribe is autonomy and trust. When there is trust, then there is ownership and accountability of the work done. Trust helps to create an environment where failure is taken as an opportunity to learn, innovate and change accordingly. This also uplifts individual morale and growth. This results in having the following benefits:
- Enhanced velocity
- Processes are reduced to a minimum
- Addresses short term challenges
- Minimized dependencies
- Lack of a firm structure makes problem solving easier
- Minimum control
- Promotes clarity and transparency
- Works best for what suits your working environment
Want to learn more about practical ways of utilising Spotify agile method? Stay tuned for our upcoming blog for
“7 steps to highly effective Spotify Scaled agile teams”
Unleash Your Organization’s True Potential to Scale Agile with Kendis
Kendis offers an all-inclusive solution to planning, tracking and managing your Program Increment and dependencies between distributed teams. It works on top of JIRA and other agile tools, your teams can keep on working with their existing JIRA boards and program level and above is planned and managed at Kendis.
Try out 10 days free trial or book a demo with our product expert.