Retrospective meetings are probably the most misunderstood and underutilized aspect of agile development.

If you know the expression, “the three most important things in real estate are location, location, location,” then you can relate when I say that the three most important things in software development are feedback, feedback, feedback. And, one particularly powerful feedback mechanism is the retrospective meeting. It’s how the developers give feedback to themselves — about their own processes.

I like to hold retrospectives early and often, at least once a week, sometimes once a day. That way, I can capture ideas while they are fresh on everyone’s minds. To make up for it, the retrospectives are kept short, 15 minutes MAX. In fact, if they go longer than 5 minutes, then something is wrong.

Why so short? In my experience, one of the first three or four items that get written on the board during a retrospective meeting is usually the one that winds up at the top of the action-item list at the end of the meeting. It’ll be an item that is weighing heavy on a developer’s mind. It’ll be a big pain-point and there will be vested interest in seeing that something is done about it. So, it’ll get mentioned early on. Then, regardless of whether the meeting goes on for another 30, 45, or 60 minutes, we’d always circle back to those earliest of suggestions anyway.

Furthermore, I’ve noticed that no matter how many action items come out of a retrospective meeting, only one of them gets acted upon before the next meeting, if that. Say that your scheduled retrospective meetings occur every two weeks. That’s a long time for an action item list to sit before it’s due. It’s thus all too easy to procrastinate, forgetting about the list until the next meeting is called — just to report that there’s been no progress.

So, this is what I do:

1. I, as the scrum master, go around the table and let everyone name just one problem (with or without a suggested solution). About half will abstain, which is fine.
2. I ask for a quick show of hands. I tell everyone to point to the person who named what they think is the most important problem to be solved next. (By the way, urgent does not necessarily mean important.)
3. We quickly debate until there is a clear consensus (happens most of the time), or 5 minutes are up, in which case we either vote democratically or the team’s technical leader (not the scrum master) decides unilaterally.
4. We then quickly discuss possible solutions to that one problem and decide on an action item.
5. We plan who will be responsible for the action item and set a deadline. I then schedule the next retrospective meeting for after that.

In other words, the rule is this: As soon as one, unanimous actionable item is found, stop reflecting! Adjourn the meeting so that someone can immediately act on that item, and everyone else can get back to doing (product) work.

• Do not produce a list of more than one action item.
• Do not keep meeting minutes.
• Do not keep talking.
• Do not pass Go.

By the way, if the action item does not get done in a timely manner, then reflect on that at the next retrospective. Was the action-item not as valuable as originally thought? Was there a lack of motivation to work on it? Did something block the action-item? Is the solution too ambitious? Can the problem be mitigated with some other partial solution, in the mean time?

If, after a second attempt, there is still no progress on the action item, then move on to a different action item. (The developer with the pain point is free to suggest the problem all over again at a future retrospective. Perhaps, by then, something may have changed in the environment or in the team makeup that can knock the action item off dead center.)