A few weeks ago, Fareed wrote about his favourite retrospectives. I wanted to follow up on this and outline what I’d consider essentials for a good retrospective.
You get out of a retrospective what you put into it. Before even stepping into the room I like to spend some time trying to anticipate what people are going to say: are there any thorny issues dogging us that I can tailor an activity to flush out into the open? How is team morale? Is anyone particularly upset/frustrated and might this disrupt things?
Much like every good story needs a beginning, middle and an end, so too does a good retrospective need structure. The details of each section can and should vary, but I like to try and keep the overall format familiar. I try and stick to something along these lines:
- 1: Icebreaker – something to get people talking. It could be summarising the sprint in a tweet, writing notes that you wish you’d received at the start of the sprint. Keep it short but make sure it’s something everyone can do.
- 2: Review actions from the last retrospective – two weeks is a long time, so it’s important to remind people where we were back then. Did the ideas we came up with fix our problems?
- 3: Data gathering – gather up the wins and losses for the last sprint, and group things into themes. We’re not trying to solve anything just yet, but give everyone a chance to raise issues for the group to consider. We’d then use a vote to decide which are our big issues for discussion.
- 4: Identify objectives – This is the meat of most retrospectives, so it’s important to keep it focussed. The aim is to discuss the ‘big issues’ in turn. As a team we’re trying to figure out why we think they’re happening, why this is a problem, and what ideas we have that might fix or improve the situation.
- 5: Wrap-up – Depending on how many issues we’ve talked about, there may be anywhere from 5 to 15 improvements that the team has come up with. This is too many for most teams to adopt in a single sprint. I tend to have them pick out no more than 3 which, as a team, we will will try out for the next sprint, and review at the start of the next retrospective.
Here’s where I like to get creative, and you should too. Doing the exact same thing every week gets very repetitive, especially if you’re looking after multiple teams. Even something as simple as changing the questions asked can subtly shape the responses differently. Consider the following questions:
- What’s slowing us down?
- What could we have done better in this last sprint?
- What’s frustrating you right now?
These are all slight reframings of a similar question, but even this subtle shift can force people to think about things in slightly different ways. This alone can shift the mood of the retrospective considerably to keep new ideas surfacing every sprint.
Some people love to talk in a small group environment, whilst others find it hard to contribute. Your job as a facilitator is to make sure every has their say and that everyone’s opinion is valued. Doing so can be tricky as often you don’t want to shine a spotlight on the quiet ones. Choosing activities which favour writing down ideas before reading them out can help in such situations though. As can going round the table one at time for ideas.
A lot will happen in the two weeks following the retrospective, so it’s important the outcomes are captured somewhere, and that the team remembers them. If the team decided to do something new in planning, remind them of this when they go into planning. Maybe get the team to make posters for the stand-up board so they see them every morning.
Of all the Sprint ceremonies I think the retrospective has the worst reputation as, done poorly, they can be seen as a waste of time. Done well however, a well executed regular retrospective will transform any ragtag bunch of developers into a self-governing engineering powerhouse. They’re not always easy, but they are the single most important hour you can spend in your sprint if continuous improvement is important to you.