As already announced in the first article the second part of the Spotify model series follows. After we have discussed the naming and the basics of the Framework Scrum in the first part, the second part is about the structure, the roles, as well as the advantages and disadvantages of the Spotify model.
The Spotify Model – Structure
Within the Spotify model there are different clusters or structures such as squads, tribes, chapters and guilds. In the following these groupings are explained with examples and finally illustrated with a graphic.
Squads
Squads are the smallest unit within the Spotify model. A Squad is comparable to a single Scrum Team. Within a squad the Product Owner works very closely with the development team to drive product development. The focus of a squad is on individual functionalities or areas of the product or service to be developed. The role of the Scrum Master no longer exists within this model, but the Agile Coach on the tribe level was introduced to support several squads. This support covers all tasks of the Scrum Master and other activities.
Tribes
Several squads form a tribe. This means that there are several individual teams, consisting of the PO and the development team, and through the Agile Coach, who supervises all squads within the tribe.
The tribes should be set up in such a way that logically self-contained product units or service areas are covered. Tribes work largely autonomously compared to other tribes, which does not mean, however, that cross-tribbe communication should not be established or maintained. Again, it is important to recognize potential obstacles and dependencies at an early stage.
Chapter
A chapter is an association of professionals within the same profession or with the same interests. A chapter extends over several squads, but remains within the boundaries of the tribe.
The aim of chapters is to enable professionals to exchange regularly on various professional topics and to help and train each other. Each chapter has one person who leads the chapter. Leadership is not meant in the classical sense of personnel management, but rather this person is responsible for creating the framework in which the chapter moves. This starts for example with the invitation for series of meetings, room booking up to the proactive invitation of experts for training purposes.
Possible examples of meaningful chapters are: Developer Chapter divided into the technology stack (e.g. Java, Python, JSON, etc.)
Guilds
A guild is comparable to a chapter. Again there is a leader or coordinator who has the same tasks as the chapter leader. The difference between a chapter and a guild is the setting of the framework. This means that guilds, unlike chapters, are not limited to single tribes, but include the staff of the whole organization.
The Spotify Model – Roles within the teams
The Spotify model is based on the agile Scrum framework. Therefore it is not surprising that the first three roles within the Spotify model are the same as those of the Scrum Framework. However, four additional roles have been established. These are necessary because the Spotify model exceeds the size of a Scrum.
In the following section all roles are briefly described to get a better understanding of the respective responsibilities and the classification within the Spotify model.
The Product Owner
The Product Owner remains unchanged in his activities compared to the Scrum Framework. This means he is responsible for product definition, stakeholder consultation, budget management, epics/user stories and backlog management.
The product owner is part of a squad, but not its leader, as the entire team coordinates itself.
The Agile Coach
Within the framework of Scrum there is the so-called Scrum Master. The role of the Agile Coach is based on the Scrum Master role, but has been expanded within the Spotify model. Thus, the Agile Coach is not only responsible for compliance with the Scrum Framework and the elimination of impediments, but should also support the entire organization in an agile transformation.
This support lies in the fact that he trains the employees with regard to agile procedures and continuously analyzes to what extent applied methodologies can be optimized so that the entire team can work even more efficiently.
The development team
The development team is not a dedicated role, but a conglomerate of people needed to complete the product or the functionality responsible for it. This means that the composition of the squads, even within a single tribe, is strongly based on the required expertise and thus influences the team composition. The total team size also remains unchanged compared to the Scrum Framework and is six to nine people. If there are too few people in the team, the probability is very high that the skills needed for product development are missing and, if the team is larger than nine people, the coordination effort becomes too great. The Agile Coach as well as the Product Owner are not affected by this count, except when they are working on tasks from the Product Backlog.
Classical roles of a development team are e.g. (order without rating):
– Frontend Developer
– Backend developer
– UX Designer
The Tribe Leader
Each Tribe has a Tribe Leader who is responsible for product development for the entire Tribe. His or her responsibilities include coordinating with other Tribe Leaders to identify dependencies and possible courses of action. Also potential obstacles between the Tribes should be identified.
The Chapter / Guild Leader
Every chapter and every guild is led by a chapter or guild leader. The task of the Chapter / Guild Leader is to ensure that the members meet regularly and exchange information on the topics they have chosen. Within a chapter, the leader is also responsible for ensuring that the subject matter experts can build up the knowledge they need for their daily work. For this purpose, chapter-internal trainings can be conducted or guest speakers can be invited.
The System Owner
The system owner is responsible for the overall system of the product. For example, Spotify has one system owner per platform on which the product is available. This means that there is a system owner for the mobile app for IOs, Android and the PC program. Depending on the product or product type, other groupings are also possible.
The Chief Architect
The Chief Architect is also an overarching role within the Spotify model. He is responsible for the overall architecture of the product and ensures that it is always up to date and that the architecture used meets the product requirements.
The Spotify Model – Advantages & Disadvantages
In this section the potential advantages and disadvantages are discussed.
Advantages
A big advantage of the Spotify model is its basic structure. This is based on the Scrum Framework. Scrum was created in 1995 and is becoming more and more popular, so that the basic structure is already anchored in many organizations. Another advantage is that the Spotify model is kept simple compared to other scaled agile approaches. It has only been extended by new roles that are mandatory. Also the composition of squads (“Scrum Teams”), tribes (“Scrum of Scrums”), chapters and guilds is logically structured and easy to understand. The scalability is based on the number of tribes that are tailored to the product world of the organization.
Disadvantages
On the one hand, one can say that the advantage of the Spotify model is its clarity and simplicity. On the other hand, the Spotify model gives no indication how to handle frame parameters within large enterprises. This means there is no advice on vision, portfolio processes or budget management at the enterprise level. For large organizations this means that they should analyze their own processes and make changes if necessary to adapt these processes to the Spotify model.
Another drawback is that the model is more than 10 years old and there is no indication from Spotify at this time as to how they have extended or adapted the model. The model outlined here is still the basic version.
Conclusion
The Spotify model is an adaptation of Scrum that worked well for the Swedish software company and is also responsible for the success of the product. This does not mean that an exact copy of the model is valid for all companies from all industries and leads to success. In my opinion this is rather a thought-provoking impulse to expand Scrum and possibly use it for your organization. If, for example, additional roles or groupings are necessary to be successful, you should make the adjustment and check if it leads to the desired result. The essence of this model is the open error culture and continuous learning. This means that the entire organization should regularly check where there are potential risks, obstacles or simply room for improvement and change and improve them in a targeted and sustainable way. The Spotify model is the result of this work.
Organizations should also not simply rename their existing structures as this does not add value. Organizational units have to be divided and structured in a meaningful way to make the model work. This varies from organization to organization, depending on the product or service offered.
What is your experience with the Spotify model? Have you already tested it in practice?