As someone that believes instilling experimentation with continuous reflection/adaption is the key to a strong foundation for high performing environments, the retrospective has become a favorite practice of mine. Recently, there was a session at Agile 2014 about conducting/fixing/repairing retrospectives. Initially, I was shocked to see the room filled up way before the start time of the session. However, when I stop to think about it, I have several pet peeves that I’ve witnessed (ok, at one time maybe did) that often lead to retrospectives that produce little value.
- No appreciation, only lessons to adapt from: One of the best things about the evolution of the retrospective from a lessons learned meeting is that people shouldn’t suit up and load their weapons. Some experiments fail and some work. If we want people pushing the limits of innovation and become high performing, we need to celebrate more. We need to acknowledge the good of trying something even if it failed. We need to appreciate how hard learning is. When I see retros that have only negative elements, people leave that room feeling defensive and afraid, certainly not motivated.
- Vague: What went well: Communication, What needs to improve: Communication. Now this might seem extreme but it’s really not that uncommon. This is an easy path to just get through the retro without any real accountability or intent. Take a look at your minutes. Do you have the words “better”, “more”, etc? If so, this might be an indicator of not very valuable results.
- Lack of focus/Too Big: Now there are times when you need to retro a large span of time with a large number of people. Your facilitation of this retro is very different from the facilitation at a sprint/team level. However, most times, helping people focus their thoughts (concerns/ideas/etc) – helps people build upon each other’s input. If one person is talking about technical debt and another is focused on customer engagement, this can be overwhelming and then difficult to decide what to adapt for the next round. I suggest leveraging brainstorming meetings to get those lists out but that a team retrospective should be focused on a collaborative goal that the team wants to work on and discussing experiments to reflect and adapt for that goal.
- No follow up: Inspect and adapt is not a one time thing. If the results of last retro are ignored, why bother? People will begin attending as a ceremony not as a value-add that helps the team. Process for the sake of process is of no value to anyone. Personally, I don’t care what practice/approach you take to help embrace continuous improvement; just make sure
- Limited/guarded participation: The “only a few people speak at the retro” is rather obvious. The one that seems to be ignored more is the “let’s do this retro and then we will have a REAL retro when so-so is not there”. Not healthy. Avoidance is not going to solve the problem and is likely to water down the value. If we want collaborative high performing environments, we as leaders, need to lead by example and support the environment to get to honesty without defensiveness. This is not easy and will not happen overnight but never trying to address the problem, only sends mixed messages to our teams.
- Minimal facilitation planning: Facilitating retros is no joke. The environment requires safety, honesty, engagement, openness, etc. If you are not thinking about the topic you want to retro and considering what would be the best approach to achieve a healthy discussion, you are not doing your job. There is a reason so many different retro frameworks exists…take time to learn the variances and why they are powerful. If you have used the same retro style every time, it’s time to plan more. Sure you may be getting results but could you be getting better results?
What are your retro pet peeves?