Why retrospectives are essential for complex projects

Why are retrospectives so beneficial?

Complex projects with many influencing factors in particular require constant adjustments to changing conditions over the course of the project. Examples of changing conditions include security, SEO, new customer requirements or employee changes. Under such complex conditions, appropriate decisions and actions require the continuous review and re-evaluation of the project status and requirements. In addition, the transfer of knowledge within the team is increased enormously, especially if not all team members are working on the same project.

In the retrospective, the team is given the space to take a step back from day-to-day business and look at the project on a meta-level. This brings to light issues that might otherwise be overlooked in everyday life. Problems of all kinds can be addressed openly, and the retrospective makes it possible to develop suitable measures to solve problems and improve collaboration. In addition, differences of opinion between team members are brought to the table at an early stage, thus avoiding frustration within the team.

Sprint retrospective - learning through "inspect & adapt"

The retrospective is therefore firmly anchored in the scrum cycle as a regular meeting for the development team, including the product owner, and is usually moderated by the team's scrum master. To ensure a continuous, evolutionary improvement process, a sprint retrospective takes place after each sprint. At punkt.de, an iteration - i.e. a sprint - has a duration of two weeks, giving the teams a regular opportunity to talk openly about all the problems they have faced or are still facing during this time. Another name for the same principle is "lessons learned".

Intro: Welcoming the team, discussing the agenda, arriving together in the protected room. Typically, reference is made to the Vegas rule and the Prime Directive. Everything that is discussed or happens during the retrospective therefore remains in the room. Unless the team decides to publish the results. The Prime Directive is aimed at a constructive and appreciative approach. This includes a mindset of unbiased and open-minded interaction; assigning blame does not fit in with this.

1. Set the stage: Team members usually bring all their thoughts and emotions from everyday life to the retrospective. Perhaps there is an acute problem to be solved or something stressful (or pleasant) has happened. The aim of the first phase is to enable the participants to arrive in the here and now and to create openness for the joint work in the retrospective. They should now leave everyday life behind them. Activating exercises or the playful articulation of the current state of mind are suitable for this. As in the other phases, it is important that everyone has the opportunity to get involved.
2. Gather Data:the aim of the second phase is to filter out the two most important topics at most, which should then be worked on together in the next phase. The Scrum Master has the opportunity to regulate the size of the problem area: Should the last iteration be analyzed in general terms according to what went well or badly? Or is there a specific problem that needs to be addressed? In both cases, it is important to create a common picture of the situation with the team. It is also helpful to include emotions when collecting data, as these often reveal the most urgent need for action.
3. Generate insightsit is often tempting to suggest solutions as soon as a problem has been identified. However, the third phase is about gaining a deeper understanding of the causes of the problem. If this step is forgotten, the team runs the risk of only tackling the symptoms. There are also helpful methods for this phase, such as imagining the perfect sprint and then analyzing the deviations.
4. Decide what to do:in the fourth phase, the team members now propose solutions and discuss them. Adhering to a few principles increases the chance of sustainable improvement for the team:
   • At the end, there should be clearly defined tasks, who does what and by when.
   • Less is often more: by focusing on a few measures as the result of the retrospective, it is easy for those involved to implement these decisions.
   • It is important to ensure that the measures are within the team's area of responsibility, i.e. that they can be implemented by the team members themselves: "The customer should..." usually doesn't help.
   • On the other hand, it is helpful to make the tasks visible for everyday operations. Be it on a board or as a visualization on the wall of the team room.
   • It doesn't always have to be tasks. Alternatively, a retrospective can also result in team rules.
5. Closing the retrospective:in the final phase, a picture of the mood of the participants is obtained and a clear end to the meeting is set. The scrum master can gain further insights from the participants' feedback: both for his working methods and about the mood of the team or important topics that still need to be clarified - perhaps in the next retrospective.

You learn better with a good mood and variety

Every retrospective is different. Even if the phases of the retrospective are run through every time, the Scrum Master can organize them completely differently. Depending on the mood in the team or the problem situation, methods are varied and adapted and questions are asked differently. This not only brings different information to light, it also provides the team with variety. Instead of"but we've always done it this way", retrospectives create a culture of joyful improvement and further development.