Achieve more with motivated people in less time: scalable agile working according to the Spotify model
Many organizations use, in some form, an agile way of working. This involves collaboration in small teams, often between five and ten people, on a prioritized list of points for improvement (whether or not in a project context). Thanks to this agile working method, more is achieved in less time. However, where agile works very effectively for this team size, the applicability for a large team is limited. More and more large organizations are interested in the benefits of applying agile methodologies within larger teams or even throughout the organization. But how do you effectively use an agile method, which is aimed at working in small teams, in a large organization with large teams? In this additional insight, we will answer this question by explaining the Spotify model; created a methodology to make agile applicable with large teams or within an entire organization. In addition, this additional insight examines the principles of the Spotify model and we explain the pitfalls that make the model difficult to implement.
The Spotify model is named after the organization in which this method originated and used for the first time: Spotify. The model arose during the growth of Spotify. First we worked with scrum, an agile method in which a small team works on a product. As the company grew, these teams grew larger and the scrum method was no longer effective. Spotify has adapted the application of the scrum method to the growing organization, after what they call 'Spotify Engineering Culture'. This method is better known today as the Spotify model.
Squads and Tribes
Scrum was therefore used as a starting point when developing the Spotify model. The scrum teams have been replaced by squads. A squad works together on the long-term objective that has been imposed on them. The way in which they achieve this objective is entirely up to them. This autonomy promotes innovation and employee commitment. Achieving this long-term goal completely independently is made possible by the multidisciplinary character of a squad, which means that knowledge and expertise is available on the various aspects that are important for achieving this long-term goal. The tasks that the squad performs are short-circuited with the product owner of the relevant squad. Similar to scrum, the product owner has the task of indicating the prioritization within the squad, but does not interfere in the day-to-day running of the squad.
In a large organization, the number of people working on the same product or service is often greater than one squad, so that several squads are set up for the product or service in question. These squads together form a tribe. Within a tribe, a tribe lead is appointed, who is responsible for facilitating a productive and innovative environment for the squads. For example, most squads within a tribe often work in the same building to promote direct communication, and they have space to hold brainstorming sessions and write down ideas, for example by placing whiteboards.
Now it can happen within a tribe that squads are dependent on each other, for example for the development of a product consisting of a few sub-products. The squads work together in this by supplying the sub-products for each other and by adjusting and coordinating schedules where necessary with the other squads, also during the projects. It is of course possible that a designated squad does not have time to deliver a requested partial product on time. In this case, another squad within the tribe can choose to develop this sub-product itself and have the result verified by the designated squad, so that the requested delivery time is met. Effectively taking over tasks from another squad is only possible thanks to the multidisciplinary character of the squads and the close cooperation within a tribe.
The Spotify model, drawn up by Spotify itself.
chapters and guilds
Where tribes and squads are multidisciplinary, chapters and guilds are classified by discipline, comparable to a department or business unit in a more traditional organization. A chapter is formed by all people with the same function within the same tribe. For example, a chapter can consist of all architects working on the same product, in one or more squads, but within the same tribe. One of the members of the chapter is the chapter lead. He facilitates a periodic meeting with all chapter members. In this way knowledge can be shared, but also joint considerations can be given to possible bottlenecks that require subject-specific knowledge and experience. In addition to facilitating this consultation moment, the chapter lead acts as a coach for the members of his chapter.
Overarching there are guilds. Guilds consist of all people with the same function or interest, both within and outside the tribe. It is also possible to be a member of multiple guilds, as long as the function or interest is appropriate. Guilds also hold periodic consultations to share knowledge and help each other. For example, a problem for which no solution can be found within a tribe can be presented to members from other tribes. This creates new insights that help to solve the problem. The solution of the same type of problem with another tribe can also contribute to the solution of the current problem. In essence, a guild has the same function as a chapter, only it consists of a larger group to spar with.
Principles of the Spotify model
The Spotify model is based on a number of principles, also referred to by Spotify itself as the 'Agile à la Spotify' manifesto, whereby the overarching principle is to facilitate autonomy for the teams. These principles form the basis for guaranteeing the agile working method.
We see many cultural aspects reflected in the basic principles of the Spotify model. For example, under the principle 'Continuous improvement' it can be read that an open culture is required to be able to implement this and for the principle 'Simplicity' there is advice to keep the lines of communication as direct as possible.
pitfalls
Despite the success of the Spotify model within Spotify itself, the model also has a number of pitfalls that can cause the model to get stuck and as a result of which it is not recommended to take over the model in another organization.
- The matrix organization, where there is a chance that it is not always clear when the tribe or chapter lead should be involved. To prevent this, it is recommended to appoint the same manager for all people within a team with the same function or in the same field.
- Too much focus on team autonomy and no attention or processes for what goes on outside the team. Ensure there is agreement across the organization, not just within teams, and processes for cross-team collaborations.
- Everyone can work together, right? If not all employees are familiar with the agile principles, the entire Spotify model can stall. It is therefore important to support the employees in this, for example by offering support in planning, collaborating and properly fulfilling the team roles.
The terms of the Spotify model are different from the terms in most organizational models. The transition to a new organizational model can be confusing at first. The 'lapse of management functions' or the replacement of current designations, such as a business unit, for example, in the terms of the model can increase this confusion. Every (new) employee has to get to know the organizational structure, so don't make it more complex than necessary.