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:
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.
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:
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:
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.