Three Ways to Make Your Agile Retrospective Relevant Again
12 Jan 2013
It’s tough to affect positive change within a team (or even individually) without a frequent feedback loop, that’s the point of holding retrospectives in an agile environment.
All too often, retrospectives become yet another habitually boring meeting every two or three weeks. It doesn’t have to go down like that, and I’ve included three tips below that I think will add life back into your retrospectives and provide new opportunities for continuous improvement.
Agree / disagree, feel free to comment here or continue the conversation on Twitter.
Choose a Focus (and plan ahead)
As Esther Derby has said previously, Every retrospective should be unique. Never begin (or attend) a retrospective if you have no idea as to what the primary focus will be, you’ll waste time and wasting time is the root of all evil.
When you know the topic, don’t be afraid to plan ahead of time as individuals. Bring evidence, data points, situations, behaviours and impacts to the retrospective. Doing so will help make the meeting itself far more productive.
As the individual running the retrospective (Scrum master or not), keep the ball moving. Avoid long periods of awkward silence waiting for group feedback or consensus.
If you find yourself with multiple focuses needing attention simultaneously, consider having another retrospective. For example, you might see need for a session at the end of week 1 that focuses specifically on the difficulties surrounding your sprint kick-offs. It makes sense to have the discussion when the situation is still fresh rather than waiting until the end of a sprint.
Track Outcomes
As part of closing the retrospective and after everything has been discussed and prioritized, record two copies of each action item.
One goes to the individual tasked with it, the other to the scrum master / team lead.
Make sure that the action items / takeaways (2-4 each sprint) DO NOT just end up on a wiki page that no one looks at until the next retrospective. If something is important enough to warrant becoming an action item, it should be made visible to each team member every day.
Record each on their own piece of paper and place them on your physical sprint board.
Which brings me to the final suggestion…
Record Incremental Progress
Throughout your sprint, whenever progress is made on an action item, put a check mark, dot or explanatory sticky on it. Doing so will help establish a positive feedback loop and demonstrate that improvement is being made throughout the sprint.
Review each sheet of paper at the start of the next sprint. A bare sheet of paper is evidence of a poorly chosen action item (but it sounded good to the team at the time, how did that happen?).
Celebrate not only the work (software, documents, hardware, etc) delivered in a sprint but also the progress made against your action items. The former is what the team is expected to do, the later is what the team wants to do.
What’s more important?