The Black Box of Scrum Team Building
The team in Scrum
Under these conditions, the Scrum framework (ideally) with the help of consistent structures and clear process rules reduces the environmental complexity to such an extent that Scrum teams work quickly and effectively, agilely and customer-oriented and with constantly high added value. The allrounder, with which the challenges of globalisation (increasingly complex competitive structures and the environment) and digital transformation (ever-increasing use of intelligent technology through to the so-called networking society) can be tackled in a relaxed manner. This is at least how grey theory works. The crux of the idea of self-organised teams in the Scrum framework, however, is the fact that the processes that play a role in team building are not considered or paid attention to at all. If a team consists of hierarchically equal individuals who are to develop their tasks in interaction with the other members SELF, the relevant team building processes are particularly interesting.
The five-phase model of the team building process
Bruce Tuckman – an American psychologist, organisational consultant and university lecturer at Ohio State University – developed a five-phase model of the team-building process¹ as early as 1965¹:
At the beginning there is the forming phase, in which the team makes the first contact and gets to know each other.
After the first shyness has vanished, the storming phase follows, in which each team member must find his place or fight for it. In spite of the propagated “eye level”, Scrum teams can also fight for power and status, just think of the much-cited example of the “star developer” in the team, who uses unspoken privileges and stands under the non-verbal protection of management outside the team. During the storming phase the productivity of the team is rather low, expressed in Scrum language: The team velocity is (still) low, i.e. in this sprint comparatively few storypoints are worked out.
The fight is followed by the norming phase, in which rules and agreements are made to enable effective working. Within the framework of the Scrum framework, these (procedural) rules for cooperation have already been defined. Here the Scrum Master is asked to bring the understanding of Scrum to the team members. He has to explain what the purpose of the daily stand-ups is or moderate the retrospective in such a way that a solution can be found that is comprehensible for everyone with regard to possible complications during the collaboration.
Despite these pre-defined rules, there will be implicit rules in every Scrum team that relate to e.g. * the expertise of individual members (how a member can profile himself as an expert in a field), * how misperformance is dealt with or how opportunistic behavior (TEAM = lazy co-working) is identified and punished.
In this context, the individual team roles identified by the Englishman Meredith Belbin in 1965 on the basis of his team research are of immense importance.² He developed a model of nine team roles, in which he identified
- three action-oriented roles (doer, implementer, perfectionist),
- three communication-oriented roles (coordinator, team worker, switch-maker) and
- three knowledge-oriented roles (inventor, observer, specialist) as relevant.
Based on his research, Belbin assumed that a heterogeneous team with all roles works most effectively.
After the norming phase, Tuckman is followed by the performing phase, in which the team – now equipped with common rules and a common identity/vision – works most effectively and has a high velocity.
At the end of the project, with the completion of the task, the adjourning phase follows, in which real “mourning work” has to be done. The team, which has worked well together, separates again. Depending on the experiences from this adjourning phase, the team members will act in a new Scrum team. Ideally, a Scrum team will reach the performing phase within the first sprint. However, since Tuckman’s model does not imply automatisms, in reality it is possible that the described phases (with the exception of the forming phase) are repeated over and over again (at worst in every sprint) or that the performing phase is never reached.
It is possible that a Scrum team, the majority of which consists of software developers who, due to their (presumably) very similar personality, expertise and socialisation, are more likely to be regarded as homogeneous, will not achieve the (role) heterogeneity necessary to enter the effective performing phase. Phenomena such as groupthink or in-group/out-group differentiation can also lead to a perception bias. Consequently, a (homogeneous) Scrum team could in the worst case even become “operationally blind”, i.e. exactly what Ken Schwaber and Jeff Sutherland wanted to prevent with the development of their Scrum framework.
It remains to be concluded that the formation of a (permanently successful) Scrum team requires much more effort than the Scrum Guide would suggest: From the “right” selection of team members to the (hardly controllable) “right” communication of values and visions. From years of personnel selection research, we know how difficult it is to assess one’s own employees “correctly”. On the basis of system theoretical logic, one’s own observation (and interaction) will anyway falsify the object of observation! In addition, individuals continually optimise themselves in their social system. They perceive the resulting forces (often unconsciously) and adapt to them, which makes a planned team development almost impossible.
In the end, the question remains what a self-organised, agile Scrum team really is, apart from the teachings of Scrum.org: Really the solution to the challenge of digital transformation? Or maybe just: old wine in new bottles?
 Description of the phase model according to Tuckmann on Wikipedia: https://en.wikipedia.org/wiki/Tuckman’s_stages_of_group_development
 Description of the team roles according to Belbin on Wikipedia: https://en.wikipedia.org/wiki/Team_Role_Inventories
 Niklas Luhmann, “Introduction to Systems Theory” Polity; Edition: October 1 (October 26, 2012)
Barbara Hilgert has published additional articles in the t2informatik Blog, including
Barbara Hilgert lives between Hamburg and Lübeck and works in Berlin. She is an agile coach, advises small and medium-sized companies on the topics of compatibility 4.0 and digital transformation and has a lot of know-how in the areas of team development and (New) Learning. "Sharing knowledge is power" is not only her life maxim, the development of this mindset is also the goal of her consultations and qualifications: Training is one of the core competencies for the future of work and an important prerequisite for collaborative networking and "new learning". She is also organizer of a #WOL-Meetup in Hamburg for exchange and networking in the North: https://www.meetup.com/de-DE/Working-Out-Loud-Meetup-Hamburg-WOL_HH/