The Black Box of Scrum Team Building

Scrum is a framework that provides a structure for agile working. The idea originated in the field of software development, as the inventors of Scrum discovered that an iterative-incremental approach with regular, structural feedback loops leads to functioning software more quickly. The teams in this framework are supposed to organise themselves, work with each other as equals and decide for themselves who is ideally entrusted with which task. Openness towards the competences of the other team members and open communication are writ large. There are no project leaders or managers, but only a group of equal developers who act at eye level with the product owner (the person responsible for the product and the interface to the volatile environment / the customer) and the Scrum Master (a coach and supporter / enabler who sees himself as a so-called “servant leader”). The focus is on the goal of developing a “working piece of software” in each iteration. The basis of cooperation is the agile mindset based on the Agile Manifesto, which all team members should have internalised.

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¹:

Forming phase

At the beginning there is the forming phase, in which the team makes the first contact and gets to know each other.

Storming phase

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.

Norming phase

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.

Performing phase

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.

Adjourning phase

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.

The team as a social system

On the basis of (Luhmann’s) system theory³ not the single individuals are the core of the consideration, but their communication / social interactions with other individuals. Organisations and teams as social systems must reduce their internal complexity in order to maintain their own borders, i.e. they must generate patterns of action and a grid of meaning, on the basis of which they place an order in the infinite variety of possibilities of the environment. Social systems must initially “lock themselves in”, in order to create afterwards an opening for the environment. Again it becomes clear that not only the current communication / interaction is relevant, but also the previous socialisation and the experiences of the individuals, because only on the basis of their (in the past established) raster of meaning can individuals communicate.

This logic also supports Belbin’s argumentation that heterogeneous teams work more effectively than homogeneous ones: the more different sense grids a social system (team) has, the more points of contact arise for dealing with environmental complexity. If, however, structures of action and patterns of meaning arise from communication and interactions, a common (company/team) vision can only be explained ex post. I.e. a team identity, a corporate culture follows communication and emerges or changes in the wake of interaction. However, this also means that given values and visions cannot be planned and controlled ex ante. Consequently, one cannot “manage” an agile corporate culture, but one can only live and communicate an agile mindset and has to wait and see what the individual team members make of it (based on their own sense patterns).

The value of openness, which is held very high within the framework of Scrum, is therefore possibly not connectable at all and may not be implemented or internalised by the team members (e.g. because a team member has learned earlier that openness is detrimental to his career). All these remarks show how complex the self-organized team building is and how many dimensions have to be considered when establishing Scrum and agile work.

Conclusion

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?

Notes:

[1] Description of the phase model according to Tuckmann on Wikipedia: https://en.wikipedia.org/wiki/Tuckman’s_stages_of_group_development
[2] Description of the team roles according to Belbin on Wikipedia: https://en.wikipedia.org/wiki/Team_Role_Inventories
[3] Niklas Luhmann, “Introduction to Systems Theory” Polity; Edition: October 1 (October 26, 2012)

Barbara Hilgert has published additional articles in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.