The Spotify Framework
When I write here under the title "Spotify Framework", this should not be understood to mean that the following presentation would represent the actual situation in the company named "Spotify", but rather primarily the situation that was presented in 2012 by Henrik Kniberg and supplemented and expanded in later publications. At best, it is a representation of a possible early step of a company that had about 600 employees at that time and can be perceived as a successful start-up company, whereas today we are dealing with an established company with more than seven times the number of employees and correspondingly changed structures. The processes, structures and procedures have changed and undoubtedly need to change. On the one hand, because the general conditions (company size, market, technology, etc.) have changed, on the other hand because it is an agile framework for which continuous adaptation and optimization is the basis of existence.
The Spotify approach is based primarily on the experience that the key success factor for any form of project or product development is always the team, its collaboration and its willingness and ability to get involved and take ownership of the project. It is therefore not surprising that what we often refer to as a Spotify model or framework is essentially a form of organization and collaboration for the team. It is of secondary importance whether a team - in Spotify we would speak of a squad - organizes its work according to Scrum, Kanban or another agile approach. In fact, squads that work together on a product and are part of a tribe can work together with different frameworks or a mixture of them, based on their skills, knowledge, and the nature of the task.
Squad
The Squad is the basic unit for the development of products. With 5-9 employees, whereby sizes up to a maximum of seven people are preferable, because above this threshold efficiency due to growing communication needs requires on average more effort than the additional people increase productivity, a Squad in size roughly corresponds to that of a Scrum team. Squads have a vision, a longer-term goal towards which they are moving with their work. They are autonomous in choosing which aspects to address, how to implement things and how to work together. Good, goal-oriented communication is crucial for this.
Communication needs and number of people
In contrast to a strictly hierarchical structure, where coordination and communication is essentially focused on a person or role that gives work instructions and receives work results and status reports, in a self-responsible, self-organized team there is a much greater need for communication between the individual members of the team. They need to consult with each other regularly to coordinate work or to be able to intervene in case of problems.
If we assume a team with 3 people, the number of communication channels is still very clear: A communicates with B, A communicates with C and B communicates with C. So there are three communication channels. If a single person "D" is added, the number is already doubled, because A, B and C each communicate with "D" additionally. So we have six ways of communication. With a team of 8 people, we already have 28 communication channels and with 9 people, we have 45. The general formula is
Number of communication channels = n * (n-1) / 2 [where "n" represents the number of persons].
In addition to the challenge of communication when the squads are too large, the fact that the manageable team size makes it possible to act like a startup undoubtedly also plays a role. Collaboration can be very informal and the team can easily decide for itself on the way it should be implemented and react quickly to new findings and events. A team spirit should develop. This further simplifies communication and supports the joint orientation towards a goal. Accordingly, changes in the squad and even temporary assignments should be avoided as far as possible, since this always causes disruptions and performance losses. Bruce Tuckman, an American psychologist, developed a phase model for team development in 1965.
Tuckmans phase model for team development
"Tuckman's model describes four successive developmental steps for groups (Forming, Storming, Norming and Performing). In 1977, a fifth phase (Adjourning) was added to the model.
Forming - the entry and finding phase (Contact)
The first phase is characterized by uncertainty and confusion. The first thing to do is for the team members to get to know each other and ensure that they belong to the group. First goals and rules are defined and the group slowly turns to the task, but the relationships between the team members are still unclear.
Storming - the confrontation and dispute phase (conflict)
In the second phase, storming, there is often disagreement about priorities when team members pursue different goals. Power struggles for leadership and status within the group occur, which creates tension between the team members. The relationships are rather conflict-laden, in the worst case even hostile, but first agreements on the organization of work are made. In this phase the group's performance is rather low.
Norming - the regulation and agreement phase (contract)
In the norming phase, standards and rules are discussed or found and adhered to by tacit agreement. The team members have found their roles and there is increased cooperation. The relationships are more harmonious, mutual acceptance increases and the team turns more and more to its task.
Performing - the work and performance phase (cooperation)
In the Performing phase, the performance of the team members levels off at a constant level. The team acts as one and is oriented towards the common goal. There is an atmosphere of recognition, acceptance and appreciation. The team members work together successfully. Roles can change flexibly between people. The team deals with each other openly, cooperates and helps each other. For this reason, task processing is successful.
Adjourning - the dissolution phase
The fifth phase, Adjourning, was added to the phase model by Tuckman in 1977. The fifth phase is not relevant for all teams. 2
Some teams often change team members during sprints because other skills may be needed in the next sprint, or (temporarily) add additional team members. This is often a way of making the best us...