When you get started, Retrospectives seem like a great idea. Many organizations use the basic “what went well, what didn’t go well, what ideas do we have” but, let’s face it, this is not a great format for a retrospective and so it is not surprising that it doesn’t produce results. As time goes on questions arise as to why we should bother with Retrospectives at all. After all, nothing really changes …

In many organizations:

• There is significant inertia around the way things have always been done, and that it is very easy to slip into acceptance that this is all there is and that it is impossible to change / improve (“learned helplessness”).

“Inertia is our enemy” - Claudio Perrone (developer of POPCORN flow)

• There is a limited understanding of what you need to do to have great, useful, impactful retrospectives. Even if you are doing retrospectives on a regular basis are less productive because some basic ideas which help are not incorporated.
• It doesn’t feel like people understand that retrospective ceremony is only part of this. Even if you have a great retrospective, if you don’t follow up and make something happen and close the feedback loop, then the ceremony is a waste. A lot of the heuristics are actually more about the follow up and feedback loop.

In my experience there are some simple do’s and don’ts that Scrum Masters can use to improve Retrospectives:

• Do understand and use a proper retrospective structure ala agile retrospectives - see below
• Do take time to do a retrospective. General rule of thumb is that if you have a 2 week iteration, you might need a 2 hour retrospective. For a retrospective for a whole quarter you might need up to half a day (depends on depth of discussion). Do not short change the retrospective. Remind people that:

“Improving daily work is more important than doing daily work” - Gene Kim, The Phoenix Project

• Do review results of previous retrospective to close the feedback loop. This reminds people that we are making progress (often we forget how bad things used to be) while establishing the seriousness of the retrospective meeting. Do not sugar coat this - if nothing happened as a result of the previous retrospective (e.g. we identified an improvement area, but didn’t follow up the item with action) then report that.
• Do spend time on what happened over the period we are reflecting on to reduce impact of recency bias
• Do identify difference between action (“we just need to do it”) and things that need capacity (“we need to plan for this”). Sometimes the improvement is “we all agree to do … “
• Do have mechanism to work “what’s next”. For example, create a story or feature and ensure it receives appropriate level of prioritization in Backlog.
• Do make sure people have understanding of effect of incremental compounding improvements ala Incremental Compounding Improvement
• Do focus. Do not try to work too many improvements at once; you just need one or two. Incremental improvement is a powerful force, but if you do not focus on a couple the whole effort is diluted. If you feel like you can do more, decrease the time between retrospectives (e.g. every week, or every few days) to keep focus on a small number of things while improving more quickly.
• Do make sure that you dealing with important issues, not just reaction to whatever is currently urgent. Retrospectives are a time to step back and invest in what is important. Trust me; there will always be another urgent crisis. Stepping back allows us to become more resilient, more able to respond.
• Do remember to work the technical aspects of your work to deliver value, especially quality. Agile implementations adopt a “quality first / zero defects” mindset to reduce the amount of technical debt incurred and the amount of rework needed and so increase capacity we can focus on true value.
• Do ensure the Team identifies improvements that the Team can work, not just improvements that other people should do. If “other people” item is identified ask yourself “what can we do to improve the situation” and lead by example. Or have two lists: “things we can do something about” and “things that other people can do something about”
• Do not go straight to “solution mode” in a retrospective. Take the time to develop a good shared understanding of what the real problem is before working to resolution:

“If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” - Albert Einstein

• Do take time to explore solutions. There are many activities which help with people really understand the problem and help develop solutions. The most common are the tools like Value Stream Mapping, Five Whys, and “Fishbone Diagrams”, but there are many more informal approaches that will yield great results. For example, you could use a version of 1, 2, 4, all to brainstorm and improve ideas.
• Do make metrics available with trended information showing what is important to the Team. For example, perhaps Team has decided to work Feature cycle time and throughput. Have this available so team can see that they are trending appropriately.
• Do let passionate people take responsibility for improvements. The best people to drive improvements to completion are those that are really passionate about a change. Even when that means that, from your perspective, you feel like you are not working the most improvement. You will have more chance of success if people are passionate about driving a change. They have “skin in the game”. Success will lead to other successes and, you never know, you idea might not be the most important thing for the Team to focus on.
• Do ensure that the retrospectives include team working agreements, team culture, and individual relationship discussions. Sometimes the best way to increase delivery of value is to ensure Team is working together effectively at a personal level.
• Do vary the goal of the retrospective, the exercises used in the retrospective, and environment (room, facilitator, snacks, etc.) to keep retrospective fresh and engaging.
• Do tailor the activities to the specific situation. For example, if you have decided on a single subject retrospective where there is an “elephant in the room” it might be better to have people identify the issue privately and then acknowledge the issue to work in the complete group (e.g. Triple Nickels activity
• Do sometimes have single subject retrospectives to deal with a specific issue (e.g. “remote team communication”)
• Do occasionally have a proactive Retrospective which offer the potential for a significant improvement.
• Do have appreciations for the Team. Ensure that the appreciation is 1 person to 1 person not “I want to thank the Team …”. This helps the Team understand the value each person brings to the Team.
• Do make use of the “Retrospective Prime Directive” to kick off the retrospective.Sure, no one believes this really, but it is an important level set for the Team. After all most of the performance of the Team comes from the system the Team is operating in, not the individuals on the Team (Deming):

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” - Norm Kerth

• Do involve the whole Team. Make sure that all Teams members have opportunity to participate. For example, there is a difference between how introverts and extroverts can participate. Introverts require time to think before speaking and so it can appear that they won’t participate in the meetings especially if you have dominant extrovert in the meeting. Understanding how to work this is critical.
• Do try different approaches. For example, one approach aimed at working the issue of making “continuous improvements” is called POPCORN Flow. The idea here is that you set up separate Kanban board to make improvement work visible and develop lots and lots of small experiments that are tracked. For those who like Japanese, this is a ‘kaizen’ approach to improvement. POPCORN flow aims to deal with organizational “Inertia is our enemy” with the view that we need to be proactive to overcome inertia and the fact that because improvements are small and continuous people will miss them and increasingly regard the retrospective as a waste of time. POPCORN flow takes the structure of a great retrospective, makes it fully visible, using a couple of additional principles to help the process. The Kanban board has states:
  1. (P)roblem and observations
  2. (O)ptions
  3. (P)ossible experiments
  4. (C)ommitted
  5. (O)n-going
  6. (R)eview
  7. (N)ext

A couple of additional ideas for distributed Teams:

• Do structure retrospective differently when working with distributed people so that you maximize use of overlapping time to do the things that are best done (synchronized) as a team (vs asynchronous). So for a standard structure retrospective:

• Set the stage: Can initially be asynchronously done in email or a text backchannel. Once the team actually meets synchronously, consider how you can bring “all the voices into the room.” Watch for safety based on who participates in any synchronous meeting. For example, you might sometimes need a special activity to surface an issue.
• Gather data: Can start solo and asynchronously. Each team member gathers their data asynchronously in advance and when the team meets, they can review the data together to gain shared understanding and agreement on the data. Sometimes people create a collection point where team members can collect data.
• Generate insights. Best done synchronously. This is tricky and often requires an experienced facilitator to help the team move through the “Groan Zone”. If you can, use video chat for this part of the meeting, so you can see people’s facial expressions.
• Decide what to do. Best done synchronously. Many teams have plenty of ideas for solving their issues. The problem is narrowing down those ideas down; to create small experiments. Be careful about running long lived experiments without intermediate check points along the way. It is best to have shorter term experiments to start with.
• Close the retrospective. Best done synchronously. This is where the facilitator confirms that the retrospective helped the team discover what they should amplify (e.g., doing well) and what they might change. If the participants didn’t feel the retrospective was effective, gather suggestions for improvement synchronously — if time permits — or asynchronously.”
• Do insist on video when doing a retrospective. This helps improve psychological safety. When we see each other, we learn together. We learn other people’s reactions and how they clarify issues. When team members can’t see each other, they miss the facial expressions and body language. Without video, people often misinterpret other people’s statements.

• Do engaged with Teams. Set the expectation that Retrospectives are being done and, more importantly, that you expect that there will be things that you as management need to take on. A good question for the Team is “What happened in the last Retrospective that I can help you with?”
• Do encourage peer discussions. Sometimes seeing another Team solve a problem that seems t be related to one they are working on will offer a breakthrough for the Team. Sometimes just seeing another Team improve will encourage other Teams to try things as well. Success breeds success.