Lessons learned from 3 retrospectives

I have now conducted three retrospectives with the same team on the same topic. I was very touched that the team wanted me back as a moderator after my very first retrospective, even though I am not an expert.

How did I come to moderate retrospectives? Well, I have always been of the opinion that organizations like to repeat mistakes. They don't like to analyze mistakes and turn the conclusions into institutional knowledge. So I took part in a wonderful adult education course, wonderful because Carina Holzmann was able to convey this didactically and experientially in a masterful way. It was the best learning experience per euro I have ever had.

When I think back on the three retrospectives, they were all different. Together with the team leader, I defined the goal of the retrospective each time: to analyze the latest product development and identify measures that contributed to success.

The first retrospective was a challenge. The team was neither familiar with the methodology nor with me and expected clear measures. However, concrete measures only emerged after the retrospective through discussions with two participants. During the retrospective, it was not easy to let the different perspectives have their say without losing sight of the structure and objectives of the retrospective.

Nevertheless, I was invited back a second time. Something must have gone well.

The team knew me and was more open to the methodology. The team itself had grown together better through the time spent together on the project. The measures developed had become much more concrete and feasible, and it was also much easier to get the team on board. Despite the concrete measures, the optimism that the product would be launched on time was restrained.

At the third retrospective, I had less time and was not satisfied with my methodological choice. But the team members were very respectful of each other and the long period of working together was a defining factor here. Everyone involved quickly agreed on the measures, so I was able to cancel part of the process without jeopardizing the result. Although I didn't feel optimally prepared, the team's feedback was positive, both in terms of the methodology and the measures. The optimism about achieving the (new) launch target was much greater.

I am convinced that retrospectives are an effective method for moving teams forward and developing solutions independently. The positive response from the team and the desire for further retrospectives show that it is an effective method.

I was happy just to be thrown into a retrospective. It helped me to quickly gain practical experience despite my self-doubt, which helped me to recognize what works and how after a self-reflection. However, I also realized that a retrospective works best when it is requested by the project management or the team. But here too, the team learned through practical experience with the retrospective.

Now I just need to find a course that answers the question: “How do I convince my own team of the usefulness of retrospectives? This is still a challenge.

Restrospective - an evolution

I conducted my second "real" retrospective. I like it, it is about people.

The retrospective was conducted the second time with the same team on product development. Each time roughly 2 hours. The space between the 2 retros was about 3 months.

There were very distinct differences between the 2 retros. The first time I did not see so much "one team". There was quite some frustration in the room, which needed some space to be expressed. But there was at least one common denominator: everybody agreed to invest time in one specific topic: process descriptions.

Other results from the first retro:

  • Confidence that things would get better after the retro was fairly low
  • Some participants considered the retro as a good starting point for the team to really come together
  • Some participants were unhappy about the lack of "concrete" measures
  • There was no conclusion on how to do it. The "how" was then discussed and elaborated afterwards by 2 participants.
  • there was no blame game

In the second retro I adapted the methodology to have one section which forced the participants to come up with concrete measures.

Before that I asked if the participants, looking back, if things had gotten better, the answer was quite positive ("yes"). But as a moderator, I could not really explain the root cause of this positive development. It cannot only be a retro.

The participants had to go through an analysis of their current experience with their collaboration and results, the take an outside in view, before developing concrete measures, SMART ones. The challenge here as a moderator was to make sure that:

  • the discussions on how to execute the measures, on the dependencies and people to conduct it, were kept to a minimum
  • the measures were indeed SMART

At the end the team was satisfied with the result BUT was still skeptical on delivering the product in time. That's a challenge for the next retro.

As a moderator I learned a lot:

  • Retros make sense
  • Retros have to be prepared well, having an idea on how the team ticks helps a lot to choose the right methodology out of a large catalogue
  • The goal of the retros has to be very clear
  • Retros are fun