I moderated most of our retrospectives in my last project, with varying success. In them, we revisit how the last iteration went and identify ways to make the next one even better. Through retrospectives, we work on constantly improving our process and teamwork.
For that to work, we need to ask ourselves “what change would help us become better”. We need to be honest about what we are not doing perfectly yet. Pointing out issues is only the first step, and we cannot stop there. Retrospectives that end after letting everybody complain are a waste of time. We always need to follow that step up with “here is what we can try to fix it”.
If we ignore that second step, retrospectives can turn into toxic bitchfests. I learned that lesson the hard way. Prompted by the exercises, participants can feel pressured into negativity. A focus on complaining can put them in a destructive mindset. Good retrospectives get them out of that state.
When pointing out problems, language has a lot of power over the tone of the retrospective. Imagine the handoff from designers to developers leads to personal friction between them. We could phrase it like this:
I hate working with our designers, they are always so difficult.
You have to look hard to find value in that statement. It exposes a problem, but does nothing to fix it. Once a sentence like that is said out loud, its negativity hangs in the room and colors everybody’s attitude. Let’s rephrase it:
Maybe we can figure out how to collaborate with the designers better.
This suggests a fix for the same problem, without dragging down the mood. It is on us as the moderators to help our teams get to that stage.