ASPECTS OF TEAM BUILDING¶

The GRPI model developed by Richard Beckhard [68] is a process model for increasing the effectiveness of team development and improving management in general. The success of an agile project depends to a large extent on the soft factors of the participants as well as on the framework conditions of the project itself [69].

The GRPI model can be used to target these:

G - Goals (Which goals are strived and how are they communicated?
R - Roles (Role assignment and definition - who is responsible for what?)
P - Processes (What processes take place and which are the procedures?)
I - Interpersonal (What about the interpersonal relationships?)

Goals¶

Goals need to be developed and communicated. In Scrum, the Developers should be informed in detail about the planned project goals as soon as the Product Goal has been developed and as soon as the first version of the Product Backlog has been created. This also generally applies to the environment and the stakeholders. Projects often go awry because not all parties involved know what is planned or because the planned activities are not communicated. Therefore, both Scrum Master and Product Owner should ensure in their respective environment that the Developers can work towards the common goal.

Roles¶

Within a team of Developers, it is first determined who is responsible for which tasks (development, test, architecture, etc.). If problems or questions arise, it is up to the team to decide who will support other team members regarding their tasks (e.g. tester explains test-driven development, or experienced developer explains development processes in pair or mob programming [70]). Each team member should be aware of their role and be prepared to perform it. In Scrum, it is the Scrum Master who is in demand as a moderator or coach in case of conflicts.

Processes¶

It is important to emphasise that Scrum as a framework provides a framework and thus defines the rules and processes. They must be adhered to in order for the process model to work. To guarantee this, they must be communicated and agreed upon among each other.

Interpersonal¶

Interpersonal relationships are characterised by the ability to communicate with each other, to respond to each other and to be able to put oneself in the other person's shoes. The sender-receiver principle [71] of communication provides an important approach: basically, all communication consists of sending and receiving messages. The model also states that it is not possible not to communicate. Indeed, even a break-off or refusal of any contact sends a signal.

When communicating, there are responsibilities:

Responsibilities of the sender: ensure that the message has been received correctly - by asking. If necessary, repeat the message.
Responsibility of the receiver: ensure that the message has been understood correctly. Possibilities are: Repeat message in own words or ask to make sure that everything has been understood.

An essential element of a Scrum Master's work is to know which stages groups go through before the Developers are optimally aligned (team building). One of his tasks is to notice if there are problems and, if so, to guide the Developers through the different stages. This model (forming, storming, norming and performing) was developed by Bruce Tuckman [72] in 1965 and extended by the fifth step (adjourning) in 1977 [73].

Agile teams are interdisciplinary (cross-functional), which means that all essential technical competences are present in order to be able to work on the project optimally [74][75][76].

If possible, the Developers should stay together for the duration of the project, members should not be exchanged. This is necessary to maintain a so-called "performing team" [77] and to achieve the best possible velocity (see velocity). The Scrum Master has the job of being the facilitator (moderator) in the Scrum project, while the Product Owner takes care of the stakeholder management.

If it is a large Scrum project, different teams of Developers can work together under the leadership of different Product Owners, in which case the overall responsibility lies with the Chief Product Owner.

The stages of team building:¶

Step 1 - Forming¶

The team consisting of interdisciplinary (cross-functional) Developers is formed by the Scrum Master in agreement with the parent organisation - and, if necessary, with the Product Owner. All the skills and knowledge required to complete the project should be available. At this stage, the team members meet at the beginning of the project. It is possible that they already know each other from previous projects or from the organisation itself; it is also possible that new members are joining.

Step 2 - Storming¶

From now on it is the Scrum Master's task to prevent potential chaos at an early stage. A team building workshop is a good opportunity to do this. All formal concerns of the agile project can be addressed here. However, there should also be enough room for social (informal) concerns of the Developers (getting to know each other, team development, appreciation for services rendered, etc.). The Scrum Master's competence in dealing with conflicts and mediating may also be required in this phase. By identifying with the project and team building measures, the daily work should be increasingly improved. But even now, conflicts can arise that need to be handled.

Step 3 - Norming¶

In this phase, the number of conflicts between the Developers decreases and they begin to adjust to each other. Different team members must quickly become a "performing team"! The foundation has been laid and the identity of the Developers is aligned with the project.

Step 4 - Performing¶

In the "performing team" everyone can rely on each other, tasks and roles are clearly defined and do not need to be discussed. In this phase the team is self-organising, the Scrum Master can focus on other issues (such as promoting Scrum in the company or dealing with impediments within the line organisation). The velocity in processing the Sprints has reached a quite stable and predictable value (processing a certain number of story points per Sprint). It is now important that the Developers do not tear their team apart or exchange team members, as otherwise earlier phases of team building may have to be gone through again. Any attempts from the line to intervene in the team composition are assessed as impediments and must be resolved by the Scrum Master.

Step 5 - Adjourning¶

When the project comes to an end, it is time to dissolve the team. It is important that all members have completed their tasks and that the roles and responsibilities of the team members have been transferred back.

The "Performing Team"¶

The performing team - what does that mean? What exactly should the Scrum Master look for when coaching his team? And how can you measure good performance?

In some cases, very different concepts are discussed in the literature on how to answer this question. In general, motivation and job satisfaction have the following prerequisites [78][79]:

Teams and the individuals within the team get the feeling that they are doing an important and valuable task/ job
General responsibility is largely transferred to them
They have autonomy in decision-making
There is no micromanagement by superiors

High performance is basically the successful, targeted completion of a task or process. Performing teams deliver good work results and are successful in their cooperation. If one transfers this criterion to Scrum, the factors would be, for example, [80][81]:

Success in the accomplishment of defined goals and tasks within the Sprints
Effective problem solving when developing tasks
Shared sense of responsibility and efficient self-management
Satisfaction of the customer or client (within a Scrum Team: Product Owner or commissioning body(ies) in the company)

What characteristics do these teams have and what factors should the Scrum Master pay attention to during team development [82]?

Effective decision-making by applying a combination of rational, intuitive and also creative methods
Targeted dealing with and resolution of conflicts within the team
Successful and effective self-organisation
Open and constructive communication attitude
High degree of mutual trust
Constructive and positive atmosphere

As a basic condition, no leadership roles or any other kind of roles (lead developer, etc.) are assigned within the team. The team is solely responsible for the success of the work. However, the team members can have different preferences amongst each other, which can also depend on the different personalities. Thus, after a certain period of time - between the storming and the norming phase (see team development [83][84]) - informal roles also emerge.

There are different personality models (e.g. team roles according to Belbin [85] or the Enneagram personality model [86]), which can be used depending on the situation.