How to Fix Weak Retrospective Action Items

If your Scrum Team regularly cites “Better Communication”, “Improve Quality”, “Less Stress”, “More Teamwork”, etc., etc. as Retrospective Action Items, consider me completely unimpressed.  I like fixing those things, but as Action Items for a Retrospective, they are milquetoast and dull.  I would also guess that if those are Action Items coming out of your Retrospective, these are recurring organizational issues that remain unresolved.  So let’s figure how to make better Action Items and maybe we can kill these recurring issues.

The lack of specificity is very common for new Teams or for Teams with a great deal of oblivion and cynicism.  Another pattern I see with Retrospectives is when it comes time for taking ownership of Action Items, no one will sign-up to implement an idea or the entire Team takes responsibility.  No one taking ownership is just sad, but everyone taking ownership is simply a defense mechanism to avoid responsibility to make Scrum successful.  For new Teams or cynical Teams, group ownership of an Action Item does not work.

What I have found quite helpful in these situations is to introduce a facilitation tool from Gamestorming – the Who-What-When Matrix .  IME, the way to break passivity, oblivion and cynicism is to restore hope.  Using this tool in a Retrospective (and any other conversation where action items are required) is one step in the right direction of bringing back hope.  When people see that they can affect positive change in their environment through a series of short, focused steps they become hopeful that things can really change.  Little changes do not look impactful in the beginning, but a series of small, easy-to-impelment changes add up over time to a big change in the way the organization feels and operates.

So now for my Who-What-When matrix:

1. Who?: Understanding who is going to be the owner of implementing an idea is the most important element of an Action Item.  It is all fine and well to talk about “Better Communication”, “Improve Quality”, “Less Stress” and “More Teamwork”, but unless someone is passionate about fixing these things there is no point in wasting more time discussing it.  Passion equals ownership, so if you do not have a lot of passion around the idea you are not the owner.  Keep in mind, the owner does not have to have the final solution for the Action Item.  They merely take responsibility to see that issue get addressed and find the right people who do have the solution.
2. What?:  This is the point we get specific on what the owner is going to do, otherwise it is difficult for the owner to follow through and for the Team members to contribute.  I tend to avoid defining the “what?” as a vague, recurring problem since they are hard to fix and often seems daunting.  While “Less Stress” is a fine a goal, what are we going to DO that makes things less stressful?  I am all for “Better Communication”, but what does better communication LOOK like?  The ideas must be specific, engaging to the owner (which is another reason why the the “who?” is defined first) and can be implemented within the timebox of the Sprint.  When defining what will be done, ask yourself, “What is the smallest thing we can do as a Team that will bring us one step closer to “Less Stress” (or whatever the issue is)?”  We do not need to solve all the communication problems of this organization in one day, but what is the Simplest Thing That Could Possibly Work?
3. When?: The last step is to discuss when the owner is going to finish their Action Item – never is not an option.  For me, setting the timer on the Action Item is essential since it reminds the owner of the urgency of what they accepted to do.  A built in timer is an excellent additional to an Action Item since it builds in a natural follow-up conversation between the owner and ScrumMaster.  At this step, I will also work into the “when?” element how will the owner report back to the Team the status or outcome of the Action Item.  In the case of reducing stress, an well-formed Action Item might say, “In a week, Frank will tell us the outcome of the conversation with VP of Software about funding a monthly team lunch.”  Or if a Team wanted to improve the quality, “By next Wednesday, Pryia will give everyone an update on testing tools after the Daily Scrum.”  That way people know exactly what is expected of them and the Team members can hold each other accountable for following through.

For more on Gamestorming, see my 2013 book review for deeper insights.