On Monday, as the new scrum master on the Vision Tasks team in Dundee, I conducted my first retrospective with the team. In this post I want to share the model we used and why it can be an effective way of running sprint retrospectives.
No process is perfect. Your team is unique, as are the situations you encounter, and they change all the time. You must continually update your process to match your changing situations. Retrospectives are a great tool for doing so.
— The Art of Agile Development by James Shore and Shane Warden (O’Reilly, 2008)
One of the principles behind Agile is that “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” (Source: Principles behind the Agile manifesto.)
This is about continuous improvement. It’s about slowly but surely getting better at what we do. It’s about recognising that our processes are not perfect, that we are not perfect, but that together we will slowly work to improve things. The Japanese have a word for this: kaizen (改善), which means “change for better” or “improvement”.
The Tasks team runs a two-week sprint from Monday to the following Friday. First thing on a Monday morning we review the last sprint and then retrospectively examine how it went: what went well, what didn’t, what can we learn from it and how can we make things better this coming sprint?
In Esther Derby and Diana Larsen’s book Agile Retrospectives: Making Good Teams Great (The Pragmatic Bookshelf, 2006) they outline five stages to a retrospective:
- Set the stage
- Gather data
- Generate insights
- Decide what to do
- Close the retrospective
Many retrospective models will follow this broad outline. On Monday I used a model that I first encountered in The Art of Agile Development and which I’ve found to be very useful for both celebrating successes and gently drawing out issues to be examined and (hopefully) resolved.
I always open a retrospective by welcoming the participants and then reminding everyone of the purpose of the retrospective: to reflect on how well the team is working together and to propose improvements—this might be to add, remove or fix something to do with their process. If we are retrospecting on a particular topic rather than generally examining the last sprint (for example, maybe we want to examine more closely our sprint planning process or story refinement process) then this would be the time to do that.
It is important that people feel safe, so I always run through some ground rules and invite the team to add or remove any. These ground rules support Scrum’s values of openness, courage, respect, focus and commitment. An example might be:
- We will timebox this retrospective to 1 hour.
- We will be honest.
- We will talk from our own perspective, and not speak for anyone else.
- We will accept everyone’s opinion without judgment.
- We will try to not interrupt.
- You may critique anything, but you may never criticize anyone
- We will not check mobile phones, email, etc. during the retrospective. If there is a phone call during the retrospective we may take the call and offer to phone back after the meeting, unless it’s super urgent.
- We will be confidential (what happens in the room, stays in the room, unless agreed otherwise). You may ask the Product Owner (and any stakeholders present) to leave the room to discuss anything. They will not take it personally.
- If anyone notices someone breaking these ground rules they have permission to call them out on it. We all have shared responsibility for ensuring this retrospective feels like a safe space.
- Anything else?
I then read out Norm Kerth’s ‘prime directive’ and ask team members to verbally say if they agree with this statement:
Regardless of what we discover today, 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.
Research has shown that if someone speaks early in a meeting, by hearing their own voice in that context they are more likely to contribute again during the meeting.
If everyone agrees with the prime directive, I hand out Post-it notes and Sharpies (other brands of stationery are also available) and invite them to reflect on the events of the sprint and brainstorm ideas that fall under the following categories:
I put labels with these categories written on them on a wall or whiteboard.
People may come up with as many ideas as they like, and they don’t need to have an idea in every category. (I always ask people to initial each Post-it note in the top left corner with the category it belongs to, e.g. ‘E’ for enjoyable; this is helpful when we start moving notes around.)
Depending on the group, they may be happy to read out their own Post-it notes as they stick them beneath the categories. Either way, I always read out all the Post-it notes at the end so they are in some way anonymous and people get to hear every idea.
Sometimes this helps inspire more ideas, so I always invite people to add more ideas if they like.
I then invite the group up to the board to take part in a mute mapping exercise. Mute mapping is a variant of affinity mapping but where nobody is permitted to speak. There are just three rules:
- Arrange related cards close together.
- Arrange unrelated cards far apart.
- No talking.
If people disagree on where to place a Post-it note, they have to come to a collective decision without speaking. Some Post-it notes may sit alone—that’s fine, so long as the group is happy with it.
Once everything has been organised, I invite the team to name the categories which I write on the whiteboard or on a separate Post-it note.
At this point, voting begins. Each team member is given five votes each to indicate which category or categories they would like to focus on during the next sprint. Individuals may distribute votes however they like—all five on a single category, one on each of five categories, or anywhere in between; it is entirely up to them. You can use small magnets if you are using a magnetic board, or dot stickers or simply pen marks to indicate voting intentions.
With voting over, the category (or categories) with the most votes get discussed. The Post-it notes are read out again and the issues are discussed and considered.
From this discussion will emerge actions to improve the team’s processes. These actions should be practical, personal and SMART (specific, measurable, assignable, realistic, time-bound). It can be really helpful to make it clear that this is an experiment: let’s try this for the next three sprints and review it again. Plan-do-check-act.
While there are many exercises to end a retrospective, I will often simply read out the retrospective actions agreed, and make sure we are in agreement about what we have decided. If there is time, I may ask the team for feedback about the retrospective itself—like a mini retrospective about the retrospective. Otherwise, I will thank everyone for their contributions and bring the meeting to a formal close.
At the retrospective on Monday the team unearthed a few pain-points: stand-up meetings are consistently taking too long, there was some frustration with how long both pull requests and UX designs were taking to be approved, and a general frustration about the number of interruptions. Do any of these sound familiar? There was no blame attributed, no finger-pointing. Instead, the team had a safe space to be honest and say, “Hey! These are the things that are slowing us down right now, what can we try to make things better?”
The actions we came up with were simple but because the team had come up with them and agreed on them, the team will be more likely to own these processes and use them. And if these things don’t work, well in a fortnight we’ll be reviewing things again and we can incrementally change things until we find the right actions. One of the strengths of Agile is that it allows us to fail fast: short plan-do-check-act cycles.
If one of the goals of Agile is to foster a culture of experimentation that constantly generates validated learning, then retrospectives are an important tool in a team’s toolbox.
As Shore and Warden note, “When your team conducts retrospectives well, your ability to develop and deliver software steadily improves. The whole team grows closer and more cohesive, and each group has more respect for the issues other groups face. You are honest and open about your successes and failures and are more comfortable with change.”
That’s got to be a good thing, right?
Originally posted on the Vision internal blog.