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
- 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.
Yves Hanoulle posted another interesting tip today…
He proposed to team members that they could…”leave the retrospective if they felt they bring more value doing something else”.
After giving the team a break, 2 members did not return.
Interesting that people believe they *must* attend all meetings.
I asked if this delivered a better outcome, he believes (in his opinion) that “the result was a better retrospective”
I’d like to explore this more to understand the messaging it gives to all parts of the team…
thanks for this nice post. Especially the tracking discussion points during the sprint (thinking lean) is an idea that helped me to think of more improvements of our retrospectives.
A need for the retrospective half way during the iteration seems for me to be connected with maybe to long iterations?
Regarding – keep it interesting and fresh – maybe there are some more useful suggestions available at: