Document Note: Retrospectives are activities done at the end of a sprint or project to reflect and learn. Retrospectives Antipatterns are descriptions of what can go wrong and how to remedy it. Norman Kerth and Diana Larsen and Esther Derby wrote books to help facilitate them in a more efficient way. When done correctly, retrospectives can have a healing effect on the people involved. Examples of common antipatterns are setting the wrong stage, skipping the insights generation step, and having a loudmouth interrupting the discussion. Retrospectives Antipatterns is a book that provides 23 common antipatterns, ideas on how to overcome them, and a personal anecdote from the author.
A retrospective is an activity done at the end of a sprint or a project in order to reflect and learn from what has happened, for the team to improve together. (View Highlight)
This was a game changer for me. Their book helped me to plan shorter, more efficient retrospectives, but also contains tools for the facilitator that helped me with the actual process of planning the retrospectives in a more efficient way. (View Highlight)
post-mortems. These are longer reflections conducted after something has gone wrong. (View Highlight)
Post-mortems are very useful as a tool for learning from mistakes. Done right, they can have a healing effect on the people involved, but are not the same as retrospectives. (View Highlight)
Setting the Stage Intro, theme, follow up on previous action points
Gather Data Collect data about how the team is working together
Generate Insights Find the causes behind the issues, understand and learn
Decide what to do Find a few action points or experiments to try in the near future
Close the Retrospective Make sure there is a concrete plan for the action points, outro (View Highlight)
When a team “solves” symptoms instead of problems, the problems will still be there, and they will show up again. As in a real Wheel of Fortune they might get lucky. Perhaps some of the things they solve might have been the real problems. But often we only see the symptoms and we rush to ‘solutions’ that don’t address root causes. (View Highlight)
make sure to generate insights before you decide what to do. Before you jump to conclusions. You can do this with a simple discussion about the issues that come up. Or with a “5 whys” interview. If it looks like a complex problem, a fishbone analysis might be useful. Examples of complex problems are “missing a deadline”, or “not following the peer review process”. Stated like this, they sound simple, but the short description hides a complexity: These problems can have many different causes. (View Highlight)
When you are in the soup, you are spending time on things you cannot improve. Instead of learning about and improving the issues you are able to change. (View Highlight)
The refactored solution is to use an activity called In the Soup, where you ask the team to divide the things they are discussing into things they can do something about, things they can influence, and things that are in the soup. When things are in the soup, they are a part of life that you cannot change. Your time is better spent accepting and finding a way to adapt to the situation. Or changing your situation by removing yourself from the soup. (View Highlight)
They have a Loudmouth in the team. In all the discussions in the retrospectives (and in all other meetings) this loudmouth interrupts and tells long stories and makes it impossible for other team members to take part. (View Highlight)
The refactored solution for a team with a loudmouth is to stay away from plenary discussions. Instead divide people into smaller groups, or even pairs, to discuss subjects. You can also introduce more writing and moving of post-its instead of speaking (View Highlight)
(View Highlight)