Theory "Team Building"
To a large extent the success of a project depends on the selection of team members. When putting together a team of Developers or an Agile Team, some things should be taken into account. Besides technical competence, which undoubtedly plays an important role, interpersonal skills should not be ignored. If you are responsible for the team composition, you should make sure that you bring people with different characteristics, knowledge and skills together as they complement each other well. This way you ensure that the team is capable to implement all tasks and assignments on a technical level (e.g. from the Product Backlog or from the Kanban board). However, you should also consider the wishes of the future team members, as they will be the ones who have to work together in a team. In addition, there are some interpersonal qualities that are advantageous for team members to have:
Ability to communicate
Initiative, commitment, enthusiasm, ability to motivate
Sensitivity, self-control, capacity for appreciation
Loyalty, solidarity, helpfulness
Conflict-solving ability, argumentation culture, fairness
Once the team is put together - whether with self-selected or predefined members - it has to work together. This won´t be perfect from the beginning, but will develop over time. Therefore, a team that exists for a long time already is called well-rehearsed. Even if the team has to develop on its own, the Scrum Master, when working with the Scrum framework, or the project manager, when using an agile method, can make some arrangements to support the team. For example, it has been proven useful to establish common rules that have to be followed. If the Scrum Master, or the other person in charge, notices an open or hidden conflict, he should help to first uncover, if necessary, and (subsequently) solve them. A culture of dispute should be created for this purpose. In Scrum, as you already know from the previous chapters, the main task of the Scrum Master is to shield the team from external influences - this helps the team to develop and work well together, because Developers, who are not disturbed, work more productively, which increases their motivation and gives them a positive attitude.
The stages of team building according to Tuckman¶
As mentioned earlier, a team needs to develop in order to eventually work well together. In the 1960s and 70s, Bruce Tuckman developed a model that reflects the stages of team development. As with any model, practice may differ from theory, but the model has proven useful as a first introduction to the topic of team development and for understanding basic behaviours.
For a better understanding, the steps of team development are explained below using the example of a Scrum Team. Of course, these steps can be applied to other agile teams as well.
Step 1 - Forming¶
A team of interdisciplinary (cross-functional) Developers is formed by the Scrum Master in coordination with the core organisation - and if necessary the Product Owner. All competences and knowledges for completing 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 past projects or from the company itself; it is also possible that new members will join.
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 way to do this. All formal concerns of the agile project can be addressed. However, there should 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 - or acting as a mediator - may also be required in this phase. Through identification with the project and team-building measures, the daily work should be improved day by day. But even then, conflicts can arise and they need to be addressed.
Step 3 - Norming¶
In this phase, the possible frequency of conflicts between the Developers decreases, people begin to adjust to each other. Different team members must quickly become a "performing team"! 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 clear and do not need to be discussed. In this phase the team organises itself, the Scrum Master can take care of other matters (such as promoting Scrum in the company or dealing with conflicts with the line organisation). The Velocity in processing the Sprints has reached a relatively 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, otherwise earlier phases of team building may have to be managed again. Any attempts from the line, such as those of a line manager, to intervene in the team composition are assessed as disruptions and must be addressed by the Scrum Master.
What happens when replacement is essential?
If individual team members leave the team and new members join, for example because people leave the company or are transferred, a change in the team cannot be avoided. The Scrum Team must be aware that productivity can be affected negatively in the short term. The whole process may start again with the first phase. It is advisable to keep turnover as low as possible. High performing teams quickly return to previously achieved performance levels.
Step 5 - Adjourning¶
As the project is getting close to an end, it is time to disband the team. It is important that all members have completed their tasks and that the roles and responsibilities of the team members have been returned.
GRPI model according to Richard Beckhard¶
In addition to Tuckman's model, which deals with team development, there is also the GRPI model according to Richard Beckhard. This is a process model to increase the effectiveness of team development and to improve management in general. The success of an agile project depends strongly on the soft skills of the participants and the framework conditions of the project itself.
The GRPI model allows these to be used in a targeted way:
G oals: What are the goals and how are they communicated?
R oles: Role definition and description - who is responsible for what?
P rocesses: What processes take place and what are the procedures?
I nterpersonal: How are the interpersonal relationships?
Goals must be developed and communicated. In Scrum, the Developers should be fully informed about the planned project goals as soon as the Product Goal has been developed and the first version of the Product Backlog has been created. Generally, this applies to the environment and the stakeholders as well. Projects often go awry because not everyone involved knows what is planned or because what is planned is not communicated. Therefore, both Scrum Master and Product Owner should ensure that the Developers are able to move towards the common goal.
In a development team, they define who works on which tasks and what they are responsible for (development, test, architecture, etc.). In case of problems or questions, it is the team’s decision who helps other team members with their tasks (e.g. tester explains Test-Driven Development, or experienced Developer explains development processes in pair or mob programming). Each team member should be aware of his role and be prepared to fulfil it. In Scrum, the Scrum Master is needed as a moderator or coach in case of conflicts.
An important part is the clarification that Scrum, as a framework, provides a frame and defines the rules and processes. In order that the process model will work they have to follow the frame. To ensure this, they must be communicated and agreed upon.
Interpersonal relationships are characterised by the ability to communicate, to adjust and to be able to put oneself in the other person's point of view. The sender-receiver principle of communication theory provides an important aid: Basically, all communication consists of sending and receiving messages. The model also states that it is not possible not to communicate. Because 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. Have it repeated if necessary.
Responsibility of the receiver: Ensure that everything has been understood correctly. Possibilities are: Repeat message in own words or ask to make sure everything was understood.