Retrospectives are a valuable ritual to have as a team, but can be quite misleading when not properly executed. I often see teams going through what they call an agile transformation, and one of the most important rituals for them is the retrospective. Only that, unfortunately, it isn’t really a retrospective – it usually feels like a collection of reports, with some blame game in-between.
I like to think of a retrospective as a continuous way of improving the way a team does work. It may sound obvious to some, since continuous and iterative improvement is the core of all this agile thing, but it’s worth reinforcing the point. Ideally, a team will have open communication and will discuss problems as soon as they arise; and also, team members will often look for improvements to make their daily life easier and to deliver better products that will make the client happier.
It all sounds great in theory, but in practice it can be difficult to do: sometimes the team is too large to communicate well enough; sometimes the team is not mature enough to talk about problems openly (this is the case where the blame game begins); and sometimes there may be just so much to do that we never stop to think about how to improve it. There are things we get used to and just accept, thinking “this is the way it is”, as much as we try to not do it. This is what retrospectives tackle most effectively, in my opinion, by keeping the team on track and pushing everyone to think and discuss improvements. Teams need to be critical about their own work, otherwise they just get stuck and become part of the process.
In Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen propose the following retrospective structure:
1. Set the stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close the retrospective
As a facilitator, when setting the stage I like to talk about why are we gathering together and what’s the structure we will follow, restating the retrospective goal. I didn’t do this before, and I often found team members giving me feedback saying that it helps a lot to know what are the retrospective activities before we start. This way, people keep focus on what they are doing, rather than thinking “Is this the moment to talk about it?” or “When are we deciding on actions?”. This is also a good moment to remind everyone of the prime directive, and I cannot reinforce enough how important it is to say this out loud before running any activity (and keep the message visible on a board so that the team sees it during the retrospective):
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.
It’s is also a good moment to invite everyone to talk. It may sound silly, but people will feel more comfortable to speak in the retrospective after they are invited to talk the first time. There’s one exercise I particularly like, which is to ask the team to describe the previous iteration (or period of time since the last retrospective) with one word. This fulfills the purpose of having everyone talking, without occupying much time but still giving valuable data about how the team is feeling. Depending on what’s the outcome here, it may be worth tweaking the next exercises to help the team to surface the pain points.
Next, there is the Gather Data stage. The goal here is to have the team sharing their views about events and facts. Naturally, each person will have a different perspective and will feel differently, even if they faced the same issues or challenges. Some facilitators try to focus only on actual events and leave the feelings aside in this stage, but I hardly think that anyone will be able to describe facts without biasing them with their own point of view.
I’ll talk here about two activities that I like to use and work very well together. First, I run the Happiness Radar, and then I use its inputs to drive an activity that Paulo calls DAKI. In the Radar activity, each team member is invited to put one vote for each of the following areas: People, Process and Technology. The vote represents if they are happy, sad or indifferent with that area.
As you can see in the image above, a color code is associated with each of the areas. This is used for the DAKI activity, where the participants are invited to write down practices that they think the team should Drop, Add, Keep and/or Improve. It’s interesting to see how clusters show up for each area, depending on how their “happiness score” is. Also, it surfaces quite well how the team is facing their problems: a lot of improve and adds may suggest positivity and new ideas, while a lot of post-its in Drop usually mean that there is a clear issue to handle.
Following Esther and Diana’s structure, we would then get to the Generate Insights part of the retrospective. However, I don’t see this as a completely separate part: I personally start questioning the team while grouping the notes in the previous activity’s last few minutes. It’s natural that, while gathering data, people will look at each other notes and will speak up some thoughts. I think there is a level of control needed, so that everyone gets a fair time to think and write notes down, but I also like to watch how the team starts discussions without much interference. Nevertheless, after all notes are on the board and grouped, it’s time to talk about it.
What I’m about to say is true for the whole retrospective, but specially in this moment: all of it works much better when you have an external facilitator. It’s very common to have team members facilitating the retrospective (in my previous projects, usually the Iteration Manager), which isn’t inherently bad, but the discussions tend to be guided by their point of view – even when they are trying not to do so. Not only that, an external facilitator will often question things that the team considers obvious (or part of the process), instigating everyone to think about their practices and talk about them. I’ve seen more than once, specially in projects where people joined after they started, that some “obvious practices” where not really obvious for everyone.
A good facilitator will challenge the team and ask the right questions so that the discussion is productive, but I’m not saying that the facilitator will solve any problem. Actually, I consider a retrospective good when I leave it thinking about more practices and improvements than I did before it – not necessarily solutions. This connects to the next phase in the retrospective, where the team needs to decide what to do. Not much will happen unless the team gets to the actions.
Deciding which actions to take is a tricky exercise. I often see teams owning more actions than they can resolve in one iteration’s time, and as a result they lose belief in the retrospective. Sometimes, also, the actions end up being way bigger than they should – or even not clear enough. For instance, “decrease build time” is a fair thing to expect after a whole discussion about how that affects the team’s productivity. It is, however, a wish – not an action item by itself. How do you say it is done? If it decreases from ten minutes to nine, is that good enough? “make the build run constantly in less than seven minutes” is slightly better, but it sounds a little too abstract yet, doesn’t it? You may know what’s the end goal, but how to get there?
When deciding what to do, the team should pick items that they can accomplish until the next retrospective. They must be specific, measurable and realistic. The team should be able to treat them as user stories – and actually, following up on their progress in stand-ups is a good way to remember that they are not just ideas. They can be cards on the wall. Coming back to the build time issue, one way to tackle it would be “Change the build scripts so that they run in parallel”. But can the team do that in time? Is there a dependency with someone from other team? If that’s the case, is it useful to narrow it down to something like “Setup a meeting with Jacob to discuss build parallelization”? That’s something for the team to decide, and the facilitator role is to instigate this discussion.
Once the team has actions and owners, it’s time to close the retrospective. Action items should have owners and must be exposed to the team visually in the next days – maybe on a flip chart, or on the story card wall if the team decides to deal with them that way. Everyone’s time must be appreciated and, of course, it’s good to take some time to check what went well and what can be improved in the retrospective itself. Hopefully, the team will have a better understand of their problems and some food for thought.
Now, coming back to the beginning: why did I say that retrospectives are misunderstood?
Because they are nothing more than a checkpoint for something that a great team does naturally every day: continuous improvement. Adopting retrospectives just because the book says so isn’t effective. Any structure or exercise is only a guideline, because in the end who makes the retrospective effective is the group of participants. This is a practice that should come from the team.
Maybe this is a good topic to cover in your next retrospective ;)
What are your thoughts?
 The top 2 rituals are daily stand-ups and user stories, also often misunderstood. ^
 The 6 thinking hats is a very good exercise to separate facts and feelings, and also pushes the team members to think differently. However, it can be very time consuming and it is not an easy one to facilitate. ^