Inspired by Carl Bruiners – he described many unsuccessful retrospectives as “Happy Clappy” or “Toothless”.

– I love the term “happy clappy”

Last weekend  I hosted/facilitated a short session at the UK Agile Coaches Gathering on “How To Improve Retrospectives”. A valuable hour or so of shared challenges and lessons. Here’s the highlights I was able to capture.

Let the Team Vent

• If you have a very frustrated team with a succession of issues, give them time for catharsis. 2 or 3 “venting” sessions to let off steam rather than retrospectives needing concrete action may actually be necessary. After the sore points have been drained, circle the team back around to actually solving some issues
• Facilitate the venting to keep it constructive, not personal and ensure they are actually draining issues, not fuelling flames

Think Lean

• Prevent batching and waiting by raising issues sooner with the potential to address improvements rapidly before a retrospective even happens
• Capture your data points and lessons as soon as they come up – on the board for the team to see every day. Discuss them as part of the stand-up
• Track activities, lessons and problems on a timeline during the project or
  sprint, not at the end. There will be less head-scratching and forgotten issues in the retrospective. It’ll be faster to get moving, you’ll have fixed more and people will feel the time spent has been more productive
• Consider setting a threshold / count of the number of issues or lessons raised as a trigger for a retrospective rather than just sticking to a sprint rhythm

Figure out what to do with “stuck” actions

• If there are recurring problems beyond the team’s control, take them off the table. There’s no point in self-flagellation. Raise them in a forum other than retrospectives
• Define a clear, workable escalation path for when a team needs support to resolve a retrospective action
• Work with “management” to clear at least 1 stuck retrospective action in order to build team trust in both the management and process – prove it’s working, worthwhile and supported

Keep it interesting & fresh

• Once a team is used to the general structure of retrospectives and using these relatively effectively, use variety to keep things fresh and interesting – see the “Agile Retrospectives” book and associated mailing list for ideas
• Retrospect on your retrospectives, – e.g. using start/stop/continue

Beware of US/UK social differences

• Thanking and congratulating each other is not a common cultural behavior in the UK. Get teams comfortable with other activities and working as a team before approaching some of the “softer” areas
• Recognise your team members may not be happy talking about how they “feel” about projects, each other, values or any other “hippy” concepts

One of attendees at the coaches gathering described a painful retrospective experience where a single member of a team effectively shot down a retrospective by refusing to participate in sharing feelings. I’ve had similar derailing experiences where a single team member didn’t want to take ownership of any actions or decisions and pulled a team with them. In both cases we just called a halt to that part of a retrospective and moved on. There’s always next time.

Deciding What To Do

• Capture actions for the team and actions for “management” independently
• Use dot voting or similar consensus-building activities for selecting actions
• Encourage people to vote for what they’re motivated to address and capable of resolving, not just items they think are important
• Limit the number of actions to commit to & address, you can always come back for more
• If you complete all the committed items, consider pulling one more new action through

Agree When & How actions will be covered

• Some items are “just go do”, others have more cost. Address just go do items as they come up
• Consider use of stories for larger actions in backlog and prioritization
• Try “sprint tasks” to keep “customer” activity/velocity independent of “non-customer” actions and improvements
• Identify owners for taking management actions to the management (typically a coach, team lead or scrum master)

Thanks to Sophie Manton, Mike Pearce and other attendees for the insights & lessons they shared at the Coaches Gathering.