Posted by: Matt Heusser
choices, improvement, retrospectives, software, training
Okay, okay. I got that line from an annoying animated gif that I never clicked. Still, last week I was in Potsdam, Germany, at a software conference, picked up a way to improve performance on team retrospectives, and thought was worth sharing.
Perhaps I should say, I co-created a weird tip, which I will explain.
The first night of Agile Testing Days, after the tutorials, I facilitated a small workshop designed to help people take the ideas home, to make them actionable. Held over beers, the event was lean beer, but followed the basic lean coffee format – identify topics for conversation, ‘dot vote’, sort, move the first topic to in-process, talk until we run out of interest, then move on to the next.
The early topic at hand was retrospectives, the periodic meeting a team has to talk about how things are going, and how to do it better. Mary, who put down the card, found that the team had great ideas for improvement, it was just that nothing actually changed.
The improvement ideas came, people ‘signed up’ to implement the change, and instead of actually changing, they scheduled meetings. Eventually the change became something out of action item man — follow-up turned to follow-up turned to dropped on the floor, forgotten.
At the next retro, the update from the colleague is that the improvement is ‘in progress’, there is no follow up after that, and then the idea is gone.
What to do?
I had an idea.
Improvement Idea: Kill The Retrospective
Let’s say Mary tracks all the improvement ideas for the past two months and finds that none of them, not one, actually happened. In that case, the retrospective is a show; it is ritual. If we look at the activity in terms of business value, it is waste.
If the retrospective truly is waste, then the best improvement idea Mary might have is to eliminate the retrospective.
Now it’s possible that the whole team agrees to kill the retro. If that’s the case, at least you sent a wake-up call that something odd is happening. A second, perhaps more likely possibility is that people tend to be argumentative and disagreeable with any suggestion. In this case, any attempt at arguing will have the strange impact of forcing them to want to save the retrospective – which is what you really want anyway.
Improvement Idea Two: Track the Improvement Ideas As Work
So put the improvement ideas on the board – at least the top one or two. Estimate them if you estimate stories, and give the team time to get the stories done, and suddenly, the work will get done.
If you conduct retrospectives, and nothing changes, propose either to kill the retrospective (to spark discussion) or to track the improvement ideas as work, to make sure they get implemented.
What’s Left Unsaid
This conversation happened at an “Agile” Conference. I suspect more than half the attendees had a regular retrospective meeting, perhaps every two weeks.
A whole lot of my readers don’t have retrospectives as a regular part of their work, especially those on general IT teams not writing software code.
If that is you, I’m curious – how often, and what do you do, to collect after-action reviews? Is it effective?
I’d like to continue the discussion, but I’d like to include a wider spectrum of possibilities than “just” scrum teams.
Thanks for the help!