| layout | title | subtitle | category | type | audience | status | phases | breadcrumbs | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
detailed-guidance |
Running retrospectives |
Reviewing a team's work and the way it was done |
agile |
guide |
|
draft |
|
|
A central principle of agile is quick feedback loops -- you demonstrate something to the user as soon as possible so you can see how well it suits their needs. Retrospectives are the way we apply this to our own teams to find out what’s working and what isn’t, so a team can continuously improve.
A retrospective is a meeting at the end of a sprint where your team get a chance to talk about what went well and badly in that sprint, and take some actions to improve matters. It can also cover a larger scope, eg a full project retrospective.
A retrospective takes this form:
- gather data
- generate insights
- decide what to do
This is a chance for everyone in your team to contribute to improving process/productivity.
All retrospectives must be facilitated. The facilitator’s role is to give everyone a chance to talk about their concerns and give positive feedback.
At the same time, they make sure the meeting remains a structured, productive meeting and doesn’t become overly negative. Ideally, your facilitator will be someone outside of your team so your whole team can contribute, but it’s not essential.
The facilitator needs to:
- plan the retrospective
- make sure that everyone gets a chance to contribute
- keep the retrospective on track
- make sure actions are created and assigned
- manage time so that it does not run over
You’ll find it helpful to have some working agreements for a retrospective. These can be stated if necessary, eg in the first retrospective your team has.
Working agreements could be that:
- everyone contributes
- no one speaks over the other (except for the facilitator)
- no phones or laptops are allowed -- everyone should be concentrating on the discussion
During the discussion you will uncover some successes you can celebrate, as well as some problems that you can fix or things you can improve.
Make a list of actions that will address these. Aim to have done them within the next sprint or iteration.
Some problems may take longer to fix, in which case you should try to make an action that will start the process of improving it by your next retrospective.
Actions should:
- be concrete and measurable (eg ‘write 10 more unit tests for the redirector’, or ‘speak to Jamie about arranging a project retrospective’; not ‘write more tests’, or ‘we should understand the lessons learned from this project’)
- have a date by which they should be completed
- be assigned to a specific person (and not to ‘the team’)
- not be assigned to someone who is not present
Retrospectives should follow up on the actions of previous retrospectives to make sure they’ve been completed. If they’re consistently not getting done, you may have too many.
##Template
{:.left}
You can use this template for your retrospectives. It’s based on a team of 8 to 10 and covers a 2-week sprint. 90 minutes is a reasonable amount of time to use for this scope and amount of people.
Each of the activities is timeboxed (has a set time it will run for), and it’s your facilitator’s job to make sure that your team stick to this.
Build in about 10% ‘shuffle time’ to move between activities to make sure it doesn’t overrun.
Explain the scope and, if necessary, purpose. If your team don’t know each other and/or are shy, include brief introductions.
Make sure they've been completed. If any haven't, ask if:
- they still need to be done
- why haven’t they been completed -- set a new deadline if necessary, but don’t keep carrying actions over
{:.left}
Give your team around 10 minutes to write down all the things that went well in the previous 2 weeks on post-it notes.
If anonymity is important to encourage free expression, collect them in and add them to the wall yourself. If not, have the team take turns adding their own post-its to the wall, possibly saying a few words about each.
Don’t allow this to develop into a discussion at this point -- you just want to gather data.
Group the post-its into common themes. If there are too many to discuss in the time you have then have the team prioritise, eg by voting with stickers.
Discuss each of the main areas in turn:
- what should we keep doing?
- why did those things go well and what can we learn?
- are there any actions we can draw out?
Give the team around 15 minutes to write post-its for anything that went badly.
Again, group the post-its, prioritise if necessary, and discuss the main areas:
- can we work out why these things went badly?
- can we work out what we need to do to improve matters, or prevent specific things happening again?
- can we draw out specific actions that someone here can take that will help?
Spend some time looking at the actions identified; assign them to people present and set realistic deadlines for completion.
Total: 80 minutes with 10% shuffle time.
It’s OK to finish early if people have said what they need to. It’s not OK to overrun -- if there is too much to say, have the team prioritise the top areas for discussion and/or book more time for the next retrospective.
##Why we do this
Having a regular retrospective means you can:
- make small improvements often, ideally before problems start to fester
- identify working practices that make you more efficient, productive or at least happier
Agile development practices will help you work better, and the retrospective allows you to fine-tune the process and your environment to your needs.
##Further reading
You may find these resources useful:
- The Agile Retrospective Wiki -- it has some very useful resources, including plans for different types of retrospectives.
- Agile Retrospectives: Making Good Teams Great.
- Getting Value out of Agile Retrospectives -- Free eBook with many exercises for facilitating retrospectives, supported with the “what” and “why” of retrospectives, the business value and benefits that they bring, and advice for introducing and improving retrospectives.
Retrospective plan photo by Anna Shipman. Voting with stickers photo by Pete Herlihy. All other photographs by Paul Downey.