Retrospectives are an important Agile ceremony (and actually they are part of many other disciplines, just think about the project post-mortem analyses) were the team gets together and “looks back on or dealing with past events or situations” with the goal of achieving a continuous improvement.
But they are also one of the most complex ceremony to set up and facilitate and many teams tend to skip them.
Their focus is on short retrospectives, the ones occurring after a sprint, so typically after one to four weeks of work. While continuous builds, automated unit tests and frequent demos are all ways to focus attention on the product, retrospectives focus attention on how the team works and interacts.
The framework is organised in 5 stages:
- Set the Stage
- Gather Data
- Generate Insights
- Decide what to do
- Close the retrospective
1. Set the Stage
The facilitator (usually the team’s Scrum Master but you can try to rotate among team members) is in charge of preparing the retrospective and then leading / facilitating the discussion.
The first task is to prepare the meeting, starting with finding a suitable venue (a comfortable & spacious room), arranging video calls / online boards for remote team members, possibly organising some light food & drinks (coffee! You don’t want people sleeping plus they are a great incentive.)
Very important is to prepare an agenda with a stated purpose for the meeting, that the organiser / facilitator sends in advance to all participants, together with time and place for the retrospective. In it, remember everyone about the working agreements (e.g., to keep mobile phones silent during the retro) and conclude the invitation with a thank you for their time.
The purpose is important. Lots of poor retrospectives end up wandering about trivial topics and end up with no tangible results or benefits.
A useful goal helps answer the question: what will achieve value for the time invested?
The facilitator should spend some time to write down a short sentence describing the hope for the retrospective.
Useful goals for retrospectives include the following – just examples:
• Find ways to improve team’s practices.
• Discover what we were doing well.
• Understand reasons behind missed targets.
• Find ways to improve the responsiveness to customers.
• Rebuild damaged relationships.
“Continuous process improvement” may work for a couple of iterations. After that, it’s stale. Switch to a different goal.
Also, the Scrum Master should always remind participants of the Prime Directive:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available and the situation at hand.
The purpose of the Prime Directive is to assure that a retrospective has the right purpose and the right culture in order to keep the focus results-oriented and to be a positive experience for everyone involved.
2. Gather Data
In this stage, the team will input their ideas keeping an eye on the goal.
The facilitator can start by collecting and listing the hard data, with help from the team: events, metrics, features or stories completed, and so forth.
Events can include decision points, changes in team membership, milestones, celebrations, new technologies—any event that had meaning to the team.
Metrics include burn-down charts, velocity, defect counts, number of stories completed, amount of code re-factored, effort data, and so forth.
Could – for example – start with a positive vibe and give everyone the opportunity to speak and tell “what have you done really well in the last iteration?”.
The simplest and most helpful technique for beginners is the “4 L” technique, where every team member has to answer:
- What did you Like about the sprint?
- What did you Learn during the sprint?
- What did the sprint Lack?
- What did you Long for during the sprint?
Another great activity is the Timeline with colour code dots:
draw a timeline that helps to remember what happened and the mention anything worth of, for example high points (mark them with green dots) and low points (mark them with red dots).
After the timeline is complete, look for interesting patterns from different perspectives.
Writing down the data is necessary to make sure that all members understand the issues but you do not need at the end to keep them, simply destroy them (known also as the Las Vegas rule: what is said in the room stays in the room).
3. Generate Insights
In this stage all the topics are filtered to see which ones do the team value the most, and therefore which ones to work on first. They are also brainstormed to cluster possible causes. Investigate the breakdowns and shortcomings. Look for risks and unexpected events.
It’s easy for people to jump to solutions once problems emerge. First solutions may be correct, but often they’re not.
The work of this phase is to consider additional possibilities, look at causes and effects, and think about them analytically.
After this, you can generate some ideas to approach the problem in the next iterations.
Typical activities in this stage are Vote and Discuss, Patterns and Shift:
Analyse the data, looking for patterns of events, behaviours, or feelings. Also look for times when there has been a shift; for example, everything was going smoothly and then the energy dropped.
Focus on section at a time and ask the group what they notice about the data.
Hand out 5 dots for people to vote on the most important issues, the ones they’d like to discuss. They can distribute the dots any way they like, i.e. they can also put them all on one topic if they want.
Order the issues according to votes and start with the topic of highest interest.
4. Decide what to do
At this point, the team has a list of potential experiments and improvements. Now is the time to pick the top items (usually no more than one or two for an iteration) and plan what to do. Sometimes teams come up with long lists of candidate improvements but too many initiatives can overwhelm your ability to change.
Be sure that team members commit to tasks. Without individual commitment, people assume that “the team” will do the task and no one does it.
This is the most important step of the retrospective and sometimes is overlooked.
So far, you’ve only voted for the issues that came up but the team hasn’t gotten to an agreement about what to do about them and that agreement is the most valuable output for the retrospective.
For a Retrospective to be productive, you need to produce the appropriate action items (including who is in charge of them) as output.
5. Close the retrospective
Finally, you need to wrap up and close the session.
End the retrospective decisively: don’t let people (and their energy) dribble away. Decide how to document the experience and plan for follow-up.
This is to make sure everyone agrees with the results and that there’s understanding of what needs to be done.
Before you end, take a few minutes to perform a retrospective on the retrospective. Look at what went well and what you could do differently in the next retrospective. “Inspect and adapt” applies to retrospectives, too.
Before we finish, please help me to become a better retrospective leader by giving me feedbacks on this retrospective.
Let’s identify what we want to keep and what we want to change for our next retrospective.
The learnings belong to the team and the team members: not the team lead and not the retrospective leader. The team needs to own them.
Finally, close the retrospective with an appreciation for the hard work everyone did both during the iteration and during the retrospective.
If you follow these simple steps, you will most likely have a successful session, with action items to improve and people to work on it.
The next step to becoming an expert in Retrospectives is PRACTICE! You just need to gain experience, learn to know your team and what works or not.