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 throughout the project. Examples of changing conditions include security, SEO, new customer requirements, or staff changes. Under such complex conditions, making appropriate decisions and taking appropriate actions requires the continuous review and reassessment of the project’s status and requirements. Additionally, knowledge transfer within the team is greatly enhanced, especially when not all team members are working on the same project.

During the retrospective, the team is given the space to step back from day-to-day operations and view the project from a meta-level perspective. This brings to light issues that might otherwise be overlooked in the day-to-day routine. Problems of any kind can be addressed openly. The retrospective makes it possible to develop appropriate measures for problem-solving and to improve collaboration. Furthermore, differing opinions among team members are brought to light early on, thereby preventing frustration within the team.

Sprint Retrospective – Learning Through “Inspect & Adapt”

For this reason, the retrospective is firmly anchored in the Scrum cycle as a regular meeting for the development team, including the Product Owner, and is typically facilitated by the team’s Scrum Master. To ensure a continuous, evolutionary improvement process, a sprint retrospective takes place after every sprint. In “ punkt.de,” an iteration—that is, a sprint—lasts two weeks. This gives teams a regular opportunity to openly discuss all the problems they faced or are still facing during that time. Another name for this same principle is “lessons learned.”

Introduction: Welcome the team, review the agenda, and help everyone settle into the safe space. Typically, the Vegas Rule and the Prime Directive are mentioned. This means that everything discussed or that happens during the retrospective stays in the room. Unless, of course, the team decides to share the results publicly. The Prime Directive aims to foster a constructive and respectful atmosphere. This includes maintaining an open and unbiased mindset; assigning blame has no place here.

1. Set the stage: Team members usually bring all their thoughts and emotions from their daily lives into the retrospective. Perhaps there’s an urgent problem to solve, or something stressful (or joyful) has happened. The goal of the first phase is to help participants ground themselves in the here and now and foster openness for collaborative work during the retrospective. They should now leave their daily lives behind. Energizing exercises or playful ways of expressing their current state of mind are well-suited for this. As in the other phases, it’s important that everyone has the opportunity to contribute.
2. Gather Data: The goal of the second phase is to identify the two most important topics—at most—that will then be addressed together in the next phase. The Scrum Master has the option to adjust the scope of the discussion: Should the last iteration be analyzed in general terms to determine what went well or poorly? Or is there a specific problem that needs to be addressed? In both cases, the goal is to establish a shared understanding of the situation with the team. It’s helpful to include emotions in the data collection process, as they often reveal the most urgent need for action.
3. Generate Insights: It’s often tempting to propose solutions immediately after identifying a problem. In the third phase, however, the priority is first to gain a deeper understanding of the root causes of the problem. If this step is overlooked, the team runs the risk of merely treating 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, team members now propose solutions and discuss them. Adhering to a few basic principles increases the likelihood of sustainable improvement for the team:
   • The result should be clearly defined tasks specifying who will do what and by when.
   • In this context, less is often more: By focusing on just a few actions as the outcome of the retrospective, it’s easier for everyone involved to actually implement these decisions.
   • It’s important to ensure that the actions fall within the team’s area of responsibility—that is, they can be implemented by the team members themselves: “The customer should…” usually doesn’t help.
   • On the other hand, it’s helpful to make the tasks visible for day-to-day operations—whether on a board or as a visualization on the wall of the team room.
   • They don’t always have to be tasks. Alternatively, a retrospective can also result in team rules.
5. Closing the Retrospective: In the final phase, the Scrum Master gauges the participants’ mood and brings the meeting to a clear close. The Scrum Master can gain further insights from the participants’ feedback—both regarding their own approach and the team’s morale, as well as important issues that still need clarification—perhaps in the next retrospective.

People learn better when they’re in a good mood and things are varied

Every retrospective is different. Even though the phases of the retrospective are followed each time, the Scrum Master can structure them in completely different ways. Depending on the team’s mood or the issues at hand, methods are varied and adapted, and questions are phrased differently. This not only brings different insights to light but also provides the team with variety. Instead of a“that’s just how we’ve always done it” mindset, retrospectives foster a culture of joyful improvement and continuous development.