Every time I ask about team's challenges with retrospectives, a recurring theme comes up: Acting on Actions.

I hear, “Our team doesn't follow through on our plans for action.” Or I hear, “Our team never identifies improvement actions.” Both are retrospective “smells.”

Smell: No Action Identified

When there are no improvement actions, if I ask further, I generally discover that the team has:

  • very short retrospectives (20-45 minutes) with not enough time to learn and think together, let alone make joint decisions
  • spent no time setting the stage or gathering shared data, but jumped right to creating lists of personal (i.e. not shared) opinions about WW/DD (went well, do differently next time)
  • thought making lists of blockers will magically cause things to change
  • spent no time actually choosing actions collaboratively that everyone buys into

All beg for the Dr. Phil question, "How's that working for you?" The most the team can expect is an opportunity to identify repeating patterns of impediments, if they keep the lists and review them over time.

In these instances, I recommend using the Flexible Framework for Agile Retrospectives to design their next retrospective, and see how that works.

Flexible FrameWork for Agile Retrospectives (from Agile Retrospectives)

  • Set the Stage
  • Gather Data
  • Generate Insights
  • Decide What to Do
  • Close the Retrospective

A great focus for the next retrospective becomes "getting the most from our retrospectives and improving our improvement actions."

Smell: Actions Identified, But No Follow Through

When the team does decide on actions, then doesn't implement them, there's a different problem. Odds are the team doesn't regard their improvement actions as real work. This gets expressed in a couple of ways:

  • The team maintains an improvement list in addition to their product and iteration backlogs.
  • Team members assume someone on the team (or everyone on the team) will remember to do the improvement, in addition to their regular work.

It might happen...and usually doesn't.

I avoid this situation by taking four small steps after deciding on the action the team wants:

  1. Find who on the team wants to commit to shepherding the action...and a backup person to work with them.
  2. Write the action on a card just like all the other stories (if it's an action that will take multiple steps) or tasks (if it's a single step action).
  3. Estimate the amount of the team's effort it will take to implement the action.
  4. Carry the card into the iteration planning meeting following the retrospective and include it in the plan.

If your team's retrospectives don't result in continuously improving your process, practices, teamwork, or methods, it's a waste of everyone's time. Try one of these techniques, and let me know how it goes.

Comments