In a typical agile software development process, sprint retrospectives are meetings run at the end a development iteration. In those sessions the team looks back on what they have done and how they have done it, and decides what they can do to improve. More succinctly, the team inspect and adapt.
In my experience, sprint retrospectives are invaluable and the most effective, timely and action-focus form of ‘review’ meeting. If run right, these meetings can be the life-blood of a development team – encouraging them to habitually build on successes and address problems.
However, sprint retrospectives can be tricky to run ‘right’ and as a result, they can be ineffective. An ineffective retrospective might be shallow – only looking at surface issues and not root causes – or it may even forget the adapt part of “inspect and adapt”.
Here are five things you can do to increase the likelihood of running an effective sprint retrospective:
- Allocate enough time for the meeting. Book an hour at least, you can always leave early if you have finished
- Structure the meeting carefully to ensure the session flows well, from a clear opening through to the definition of actions at the end
- Use engaging (and fun, even) activities throughout the session
- Vary those activities each retrospective to ensure that these regular meetings stay fresh and challenge attendees to look at things from a new perspective
- Be tenacious when it comes to creating a small number of concrete, actionable tasks at the end of the meeting. These actions are the real value of the retrospective – the teams adaptations and the mechanism through which they will improve.
I’d recommend doing all those things, but I’d like to focus on how to structure the meeting.
How to structure a retrospective
Below is a retrospective structure popularised by Esther Derby and Diana Larsen in their book Agile Retrospectives. It has five sections, each with a specific goal.
- Set the stage – Goal: Set the tone and direction for the retrospective
- Gather data – Goal: Create a shared memory; highlight pertinent information and events
- Generate insights – Goal: Think creatively; look for patterns, themes and connections
- Decide what to do – Goal: Generate and prioritize valuable, clear actions
- Close – Goal: Summarize and end the meeting
For each section of the meeting, you should plan an activity (which could be simple as each person saying one word about a chosen topic) that meets the requirements for that section and progresses the team along their mission to “inspect and adapt”.
To help me think about the flow of the session, I like to visualise the retrospective structure like this:
We open up the session, collecting information and ideas. We then analyse that data, making novel and creative connections before starting to draw the meeting to a close where we prioritize and identify a small number of concreate actions.
Once you become familiar with the stages of the retrospective and what needs to be achieved, it’s fairly easy to try new activities (or come up with your own) to keep your retrospectives feeling fresh. You can find lots of activities to try out on the Agile Retrospective Resource Wiki or plans-for-retrospectives.com.
Going to Agile 2014?
If you are going to Agile 2014 in Orlando later this month and you’d like to hear more about how to run an effective and engaging sprint retrospective then come along to the workshop I’m running with Michael Upton – What’s wrong with sprint retrospectives and how to fix them – on Tuesday, July 29.
Was this article helpful?
Also in Software development
When deploying new versions of a centralized application like a web service, there’s a strategy you can use to direct production traffic to the new version only after it has been successfully de...
Also in Blog
Source controlling database code and automating deployments is a tricky business. To work quickly and maintain control over changes, developers need both productivity tooling to help generate code qui...