How productive are your teams’ retrospectives really? Do you get the most out of them? Maybe you are stuck in anti-patterns that prevent your retrospectives from being vehicles for real continuous improvement.
Participants of our Agile Kitchen session on August 9th at Spoor 18 in beautiful Mechelen had the chance to have a retrospective about retrospectives with Frederik Vannieuwenhuyse and Philippe Vandessel and got to learn about common anti-patterns and how to avoid them.
During this session Frederik and Philippe took participants on a ride through good practices for great retrospectives, starting with showing the poor practices.
What is a retrospective?
A retrospective is a recurring meeting that is very common in (but not limited to) an Agile environment. During a retrospective, the team reflects on what happened during the last period and identifies actions for improvement going forward.
Retrospectives can be a great tool for teams to achieve real continuous improvement! However, retrospectives are often not generating the desired results because teams are stuck in anti-patterns that prevent them from getting the most out of their retrospectives.
First step: recognize the anti-pattern
In order to be able to resolve and prevent anti-patterns that sabotage the success of your retrospectives, you first need to be aware of them and learn how to recognize them.
For example, the whack-a-mole anti-pattern in which a team discusses and tries to improve everything that’s happening in a sprint, resulting in little or no improvements in the end, is a very common anti-pattern. The improvement issues keep on popping up, and the more you try to improve little things, the more minor problems appear, without any structural improvements made in the end.
But there are many more anti-patterns that can prevent you from achieving great results with your retrospectives. Frederik and Philippe touched upon some of the very typical anti-patterns that impede teams’ progress:
- Anti-patterns in planning
- Death by postponement. Retrospectives that never take place, cannot generate any results.
- Lack of preparation: for example constantly using the same format such as start, stop & continue doing
- The “Let’s get it over with”- sentiment. Having a retrospective just to tick the box.
- Anti-patterns in people
- Silent team members versus loud ones. The challenge lies in encouraging the more silent people to voice their insights and temper the louder team members’ enthusiasm.
- Lack of trust. Retrospectives will only have effect when everyone feels safe and there is mutual trust to build on.
- Negativism sabotaging the effectiveness of the retrospective
- Lack of accountability: no one takes responsibility for the actions discussed, so in fact nothing happens as everyone assumes other team members will tackle the task
How to deal with those anti-patterns?
Every stage has its very own anti-patterns and recognizing them is the first step to prevent them in the future. But then how to deal with them?
In this Agile Kitchen session Philippe and Frederik gave the participants some very concise ideas on how to approach and solve the anti-patterns during different stages:
- Setting the stage
- Do not ask “Is everyone ready for the retro?”. Rather do an icebreaker with a check-in during which everyone says at least 1 word.
- Avoid smalltalk taking over the retrospective
- Data gathering
- Do not use all the gathered information. Instead, help your team decide to move on.
- Avoid that dot voting favors the majority (e.g. the number of developers exceeds the number of POs). The solution could lie in minority voting or in consent decision making where the Scrum Master makes a proposal.
- Be aware that dot voting might become political (e.g. voting last). Silent or anonymous dot voting could be your solution.
- Generate insights
- Do not focus on symptoms rather than on the underlying problem. Understanding the root cause is paramount and the 5 Whys can be a useful tool.
- Avoid jumping to solutions
- Although the 5 Whys can be very useful, avoid using this tool when there are several causes. Try to split in different tracks. The aim is to find parameters you can influence as a team.
- Steer away from identifying many “problems” that “need” to be solved. Instead discuss the obstacles and the opportunities to reach your team’s goals.
- Deciding what to do
- Avoid ending your retrospective with a feeling of “we will try and see what we learn”. Instead try to make the expected outcome concrete and explicit.
- Do not whack a mole by tackling urgent operational stuff but try to tackle structural issues.
- Issues out of the circle of influence need to be tackled differently and the scrum master can play a role in taking these issues away.
- Make sure to summarize the conclusions. Ask the retrospective participants for feedback.
Interaction makes the kitchen buzz
During the very interactive Agile Kitchen session participants got the opportunity to get to work with the theory! They formed groups in line with their experience with retrospectives, and chose an anti-pattern. Then they were asked to apply the 5 Whys to the chosen anti-pattern and generate an experiment resulting in great experience & practice sharing.
Needless to say that this interactive Agile Kitchen session with Philippe and Frederik brought many interesting insights!
Are you curious about our Agile Kitchen sessions? Please check out our Agile Kitchen calendar to subscribe to our next sessions!