Uncharted Waters

Nov 4 2013   2:56PM GMT

One Weird Tip To Improve Retrospectives

Matt Heusser Matt Heusser Profile: Matt Heusser

Notes from Lean CoffeeOkay, 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 Story

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

A Scrum-Style Task Board If a team uses a “board” to track work, then by default, things that get attention will be the things on the board.

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.

That’s it.

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!

2  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • testchick
    Great post Matt! I love the reverse psychology tip of sparking the conversation to kill the retrospective. I think that in a lot of cases that would the the wake up call many people would need to spark the motivation to get something done. If that happens, then using your second tip in conjunction with the first one could be the magic touch.

    I've worked in many waterfall environments and retrospectives are called Post Implementation Reviews, and happen only after the release is live, often only once every few months. In those environments they seem to be even more wasteful as it has been so long since dev/testing has finished, teams have moved on to other projects and are (potentially) already making the same mistakes. 
    30 pointsBadges:
  • duncnisbet
    We did this!! We would discuss the actions from the retro in the daily standups, if applicable, which meant we didn't need to spend valuable time discussing their progress in the next retro.

    This developed into the idea of a daily "mini-retro" which one of our colleagues brought back from an Agile conference - people would capture the things they wanted to discuss on a Kanban board throughout the day & we would discuss in the following days standup. 

    The actions from the mini-retro could be discussed in the fortnightly retro if required. Overall the the result was that a lot of "noise" was removed from the fortnightly retro so that the team could focus on the "bigger" topics which required deeper discussion & double loop learning.
    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: