Retrospectives are boring and useless — or are they?
By Gitte Klitgaard (experienced agile coach whose main working tools are ‘listening and caring.’ Gitte is part of the organiser team at German Agile Coach Camp and will be running her ‘Whole Team Communication’ course in Central London this October)
Way too often I hear people say retrospectives are useless, boring, that take too long. “Why spend an hour sitting in a circle and discussing stuff when we can do some coding instead?” “It doesn’t make any difference anyway.” “We talk about the same stuff time after time after time.” Etc. Etc.
My experience is that, if this is your experience, your retrospective is not being done right. So do it right and gain some value from it :)
It’s very easy to have a meeting with no result. Maybe the team complain, they vent, or talk a bit, and then head back to work. Next week they come back and nothing changes.
If this is how your retrospective is, no wonder you don’t see the value of retrospectives. And that makes me sad.
You see: I love retrospectives :)
It is my favourite tool, no matter if we do agile, waterfall, or anything else. It’s even valuable to use in our private lives.
Where else do we have the opportunity to take a step back and look at what we’ve done? The retrospective is where the team have the opportunity to dive into the process and look at things that work, and things that need to change. And, not least: actively do something about it.
Abraham Lincoln said: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe”- and that’s what a retrospective is about. Our axes in the IT world are our brains and our process. We need to stop so that we can reflect, improve and sharpen our “axes.”
My experience is that, if we don’t have a meeting to sharpen our axes, it rarely or never happens. We have really good intentions, but then everyday work occurs.
The purpose of the retrospective is just that: to take the time to reflect. We look at what worked, what didn’t work for us, and which kind of experiments we want to try.
There are some bare minimums for a retro to be effective:
- There needs to be a structure
- You need to have focus on the process
- You need to leave with action points that you follow up on next retrospective
It is not a meeting where you:
- Complain (though venting can be helpful sometimes)
- Focus on who is to blame
So, “how do I structure a good retrospective?” you may ask.
And I’m so glad you asked. Just keep reading :)
How to run a good retrospective?
As I already said: I love retrospectives :)
And especially when working in an agile way.
A lot of people have heard me ask “What is the single most important thing in agile?” Either in my talks or when I coach them.
The answer is off course: ”Inspect and adapt”.
Let’s jump right into it:
Make sure you book room and time in your calendars to have retrospectives, or it won’t happen. People have lots of good intentions about stopping and thinking about improvements in their daily lives. Sadly my experience is that it almost never happens.
There are many other things that can help make good retrospectives, and many different aspects of having one. In this post, I will focus on process and structure.
There are some things necessary for a retrospective to be effective:
- A focus on the process
- A structure to the meeting
- End up with action points (and follow up next time you meet)
The Process
It’s important that a retrospective focuses on the process. The purpose is to improve your process and learn from what happened by identifying what went well and what didn’t.
It’s very easy to forget this and start discussing who’s at fault. It is not about the person, it is about the process that you use.
I personally use the Prime Directive from Norm Kerth to set the stage from the beginning. It has been around for a long time and provides continuous value.
“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 also important to focus on process when looking at action points at the end of the retrospective.
Structure and Action Points
No matter how I facilitate the retrospective, I almost always use a structure from the book “Agile Retrospectives” by Diana Larsen and Esther Derby
It is a really good structure:
- Set the stage
- Gather data
- Generate insight
- Decide what to do
- Close the retrospective
Or in other terms:
- Getting ready to go.
The most important thing is ensuring everyone knows:
a. What the topic of today is
b. What the time frame is that will be discussed
c. Any particular focus (if it exists)
d. Who is participating
e. What the status of the actions points from last time are
2. Looking at the information at hand.
What happened since last time? It’s important to be as objective as possible. Use whatever artifacts have been created, (in scrum it could be the burn down chart, in Kanban a picture of the board every day, etc.); remember the good stuff as well :-)
3. Learn from it.
This stage is about finding the significance of the data you have gathered. Do you see any patterns? Are some things connected? Are these things within your sphere of influence?
4. Choosing what to do until next time.
Which experiments can you do to solve a problem, to make sure you keep doing good stuff, or just to try something new?
Choose a maximum 2–3 action points for next time. It’s important that each action point is very concrete and that there is an anchor-person for each point (this person is either the one doing the action, or the one reminding the team what they agreed on).
5. Last point is about getting ready to leave.
Look at the retrospective;
a. Did it work?
b. Do you need to do something different next time?
c. Does everyone know what they agreed on?
d. Does everyone know what they need to do?
The picture below shows the structure. Perform the five steps, incorporate the new experiments, and after the iteration, you have a new retrospective.
And then what?
Other stuff that can add value:
- Having an external facilitator (it can be someone from the outside or someone from another team)
- Making sure there’s room for everyone to reflect and speak
- Creating safety for people to speak up in
- Having different kinds of retrospectives
- Having different people in the retrospectives (like other teams you work alongside)
If you follow the structure, have focus on the process, and create action points every time, you are well on your way.
There are plenty of tools out there that can be helpful in each step, and a lot of them are even available for free.
I also have really good experience with asking for help and many experienced facilitators (including myself) are willing to answer questions on twitter and via email.
Good luck on improving your retrospectives — you can do it :)
