How we do a retrospective

I consider the retrospective to be the most underrated meeting in the Scrum Flow. Since it is not about the concrete results of the project, there is a certain temptation to ignore it. It is easy to fall in to the trap that “there is always something more important to do.”

Still, each Sprint should produce two results: 1) A product or service which is an increment of functionality closer to delivery and 2) a better, happier, more productive team. The retrospective is the primary opportunity for achieving the second result.

There are many ways to do a retrospective. Variety is the spice of life, and few areas are in need of more spice than a retrospective. So feel free to vary your approach, the questions, the focus, the location, the moderation, etc to keep the energy level up. The retrospective format described below takes about 2 to 3 hours, depending on the size of the team and your timeboxing. I like to use this format when getting started. It is also suitable for reflecting on a longer time-frame, e.g. a quarterly release or for reflecting over organizational boundaries.

A retrospective should identify and prioritize actionable suggestions to improve performance. As moderator of a retrospective, my goal is to get everyone to contribute to the discussion. I seek to channel discussion and debate to the proper moment, but also to prevent un-constructive discussions. I usually go through the following steps:

1. Establish safety
2. Identify the facts
3. Identify the team’s strengths
4. Collect ideas for improvement
5. Consolidate and prioritize the ideas.

Establish safety

Why establish safety? Very simple, so that people can talk freely about what happened and what could be better, without fear of consequence. If people are afraid of the consequences, they will be unwilling to talk about substance.

Sometimes it can be helpful to talk about the retrospective prime directive. I have also asked each team member to introduce him or herself and answer some questions about the story of their lives. And sometimes it is even useful to have a secret vote on how secure people feel about talking about their situation.

For the remainder of the retrospective, the following pattern is an easy way to get everyone to think about the question at hand, communicate their most essential points, and listen to what the other people have to say.

• individual reflection – each person, thinking for themselves, writes down their points on sticky notes (one idea per sticky note!), then posts them to a common area on the wall. I usually time-box this to 2 or 3 minutes and encourage everyone to write down at least 5 points.
• presentation – each person presents to the group what they wrote down. (I strictly time box this part to 2 minutes per person). Clarifying questions are allowed. Debate is not. No-one has to defend themselves while presenting their facts or ideas.
• group discussion/debriefing – after everyone has presented, then I let the group discuss what they have heard. This is also my opportunity to ask illuminating questions about the topic.

So each of the following points goes through the same scheme of reflect – present – discuss.

Identify the facts

Here I ask the team ‘what happened?’ This is about facts and events, not opinions or judgements. The idea is to build a common understanding of what happened and what was important during the period. If this is a sprint retrospective, then then time frame is simply the sprint. Sometimes a team will want to reflect over a longer time period, say 3 months.

I like to draw a time line on a flip chart in landscape format, then I draw a 🙂 and a 🙁 on the y-axis. Just as the people are about to put their stickies on the wall, I ask them to position the sticky horizontally in time and vertically by how it moved them (happy or sad). The resulting distribution paints a surprisingly clear picture of the team’s emotional state. (BTW – I discourage the team from thinking about high and low points while they are writing – that’s already focusing in, which is contrary to the objective of this step, i.e. is to open up and let the information flow).

On debriefing, I first ask if the team has forgotten anything important. Then I continue with a very open question to start the discussion (‘OK guys, what do think?’ or ‘How do you feel about what you see?’) Often different participants will have brought up complementary or even contradictory perspectives on the same event which are worth illuminating in more detail. (My favorite example: Sales: ‘I asked development for estimates but, as usual, they didn’t have time. So I had to estimate the project myself.’ Development: ‘We got yet another project from Sales which had been estimated without our knowledge or participation.’).

Identify the team’s strengths

I do not ask the team what it does badly. I think this gets people focused on the negative which is not helpful to improvement. I much prefer the positive formulation: ‘what do we do well’?  I like to ask this question for two reasons. 1) It gives the team a chance to pat itself on the shoulder — and it may need the opportunity if the results of the previous step were too ‘bottom heavy’. 2) I can see how well the team is functioning as a team.

Sometimes, after the team has presented its tickets, I ask the people ‘what should be on the list, but is not’. I don’t ask them to produce tickets, but just think about the issues.

If the team is performing at a high level, I would expect to hear them talk about craftsmanship, conflict and attention to results:

1. Craftsmanship. A software team should be good a building software and master many of the modern engineering practices. So I would like to hear about their continuous integration server, their test processes, their pairing, their source code control, etc. If they are doing good engineering, they should be able to talk about it.
2. Conflict. A well functioning team should be able to argue passionately about the subject matter, make decisions, commit and move forward. I like to hear evidence that the team is able to work effectively as a team. For instance: ‘It is the power of the argument, not the positional power which determines the winning argument.’
3. Attention to Results – The team should be producing something which  a customer wants. So I would expect to hear about releases, communication with the customer or feedback from the user. In particular, the quality of requirements being presented to the team for implementation.

Obviously, if anything is missing, I will ask the team about the current situation: “I would have expected a top team to be proud of the their approach to testing. I don’t see anything about testing. How do you handle testing….?’

Collect ideas for improvement

The last question for the team is, ‘What could we do better?’ The objective is identify concrete improvement potential which the team could start working on tomorrow. Ideally the team has been well primed based on the previous discussion to come up with good ideas.

Consolidate and prioritize the ideas.

This approach produces many ideas. Too many, to implement all of them. Many will be duplicates or multiple suggestions to address a more fundamental problem. So after all the ideas have been presented, you need to create some order from the chaos. The team has to decide what it will really do.

As moderator, I go through the tickets one by one and ask two questions:

1. Who can fix this issue, the team (people in the room)? Or is help from someone else necessary (e.g. management, another department)?
2. Does this tickets belong together with some other ticket, or is it a new issue? For instance, there might be three different suggestions related to testing, and these might get grouped together on the common theme.

I usually group the tickets in two columns, one for own jurisdiction (the team can address the issue itself) or one for foreign or shared jurisdiction.
If there is some doubt as to who has jurisdiction over a particular problem, it is helpful to trim the scope of the ticket so that them team can take responsibility. Otherwise, negotiation is required with a third party, say management or another department. This will at least take time and may even call into question whether the idea can be implemented. A team can move much faster on issues for which it has jurisdiction. (Non-Scrum teams are often totally dependent on their management to get any improvements done at all! – No wonder Scrum teams are faster!!)

Once the tickets are grouped and consolidated, the team can prioritize the improvements, e.g. using dot-voting. Depending on the number of tickets in each column, the team might vote on each column separately or both columns together.

At this point the team has a prioritized list of improvements it can make to improve its performance and/or make it a happier team. Usually I suggest that the team stop at this point. The next day, just after the daily Scrum, the team should decide how many of the items it wishes to take on for this sprint and how to tackle those items.

It is better to commit to and succeed at implementing just one improvement rather than to commit to too many ideas and not get any of them accomplished.

I suggest taking a picture of the results and posting them to project wiki. I do not suggest keeping track of suggestions you decided not to implement. This list would become heavy baggage to carry around. If the issues are important, they will resurface in a future retrospective. It can however be quite satisfying to keep track of the improvements that you have actually implemented, both for you and your management.