During Agiles Argentina 2016 (http://aa2016.agiles.org) Juliana Betancur and I led a session to answer this question. How do we carry out more effective retrospectives? This article is a brief summary of what we talked about. So, let me tell you a story.
The woodcutter story
Once upon a time, a very strong woodcutter asked for a job to a timber merchant and he got it. The pay was really good and so were the working conditions. For those reasons, the woodcutter was determined to do his best.
His boss gave him an axe and showed him the area where he was supposed to work.
The first day, the woodcutter brought 18 trees.
“Congratulations,” the boss said. “Go on this way!”
Very motivated by his boss’ words, the woodcutter tried harder the next day, but he could only bring 15 trees. The third day he tried even harder, but he could only bring 10 trees. Day after day he was bringing less and less trees.
“I must be losing my strength”, the woodcutter thought. He went to the boss and apologized, saying that he could not understand what was going on.
“When was the last time you sharpened your axe?” the boss asked.
“Sharpen? I had no time to sharpen my axe. I have been very busy trying to cut trees…”
Beware of Anti-patterns
Ok, I got it. We need to do retrospectives at the end of the Sprint so we can learn and be a better team? And why do we always discuss the same issues over and over again?
When we don’t have a guide, it is very easy to fall into this pattern.
CATHARSIS: Some teams use their retrospective time to blame each other, they drain all the anger from their system to feel better. Then, as if nothing had happened, they prepare to work again on the next sprint. I’m sure we can easily notice that this doesn’t work at all.
PURE WILL: Sometimes, when we don’t vent, we choose to start acting in a more professional way and we decide, “this is enough, we need to do something!”, and we all agree on that. We discuss what a better way to work would be, but apart from talking about this during the retrospective time, no one takes ownership or commitment to actually do or try an action item. Retro after Retro we keep discussing the same things over and over again.
DIFFUSED ACTIONS: Ok, what’s the problem ? “We have a lot of bugs”. So, after discussing it for 45 minutes we get to know a lot about why we have bugs and we agree at a high level that in the next sprint, “Let’s have less bugs!”. That’s great, but “how are we exactly going to do that?” We haven’t been specific about something we can act on – an action.
SHRINKING RESPONSIBILITY: “I want to develop this feature faster, but the computer is too slow”, “internet goes down all the time” , “he needs to teach me how to do it”, “my project manager does not answer my emails” and so on. We put ourselves in a helpless position, “I want to do a better job but they won’t allow me”. How can we take responsibility for what is in our hands to solve? Avoid wasting time on things that are out of our scope and ask for help from others when we need it.
Agile Retrospectives, a book by Esther Derby and Diana Larsen (source of image), describes a retrospective framework to avoid these situations by guiding the team through different steps. For each step, we can use a variety of activities, depending on the time, location and maturity of the team. Next, I am only going to explain the steps, and then I am going to tell you my favourite dynamics on future publications.
Before we start, let’s check if we were able to do the Action Item from the previous sprint. What was the problem we we were trying to solve in the first place? Then, if we carried out the action, and it was successful, should we standardise that change into our process? If we didn’t accomplish the action item, ask why? What prevented us from doing so? etc.
First Step: Set the Stage
On a 2-week sprint iteration, we will have 1 or 1,5 hours to do the retrospective, so we need to reduce the number of topics we want to discuss. There always are one or two main topics, let’s talk about those first. Find a way to get the most relevant 1 or 2 topics. This is a convergent step where we want to decide what are we going to discuss during this short period of time. Try this activity: Everybody summarise the sprint in one word. Give one minute to explain the word and then vote.
Second Step: Gather Data
Now we can start adding some data, usually we have 2 kinds of data:
- Hard Data: Facts and Numbers like Velocity, # of Bugs, # of Deploys, # Carryovers…
- Soft Data: How did you feel the last sprint? What are the things that bothered you? What were the events, situations or impediments that you consider impacted the most in the sprint?
Third Step: Generate insights
We have a lot of information from the previous step, let’s organize it and talk more in depth about the root cause of those issues. Pick the most important stuff. Analyze those items from different points of view and start thinking about how to improve the process. Try this activity: Brainstorm of ideas, then do a or 5 Whys or Fishbone exercise.
Fourth Step: Decide What to do
Ok, let’s focus on what to do… What are some experiments we can try? What can we improve as a team? Let’s see if we are able to adjust our behaviour to improve how we work or avoid situations that may be the cause of lower performance. I like to do this as a S.M.A.R.T. experiment (Specifc, Measureable, Achievable, Relevant, Time-boxed). Write it down in your tracking system and make it part of the next sprint planning.
Fifth Step: Close
We are a group of people working together, but if we want to be agile, we need to be a team. So, now it’s the moment to do a team building exercise. Thank and/or recognize your team members for helping you during the iteration.
By following these steps your retrospective will be more effective, you will be able to design your own retrospective, you will discover new activities to do for each step, and the best thing – you will not forget to Sharpen your axe!
Ágiles Argentina 2016 – Graphic Facilitation by Juliana Betancur @julibetancur