Way to often I hear people saying that retrospectives are useless, boring, take to long; ”Why spend an hour sitting in a circle and discussing, when we can do some coding instead?” ” It doesn’t make any difference anyway”, ”We take about the same stuff time after time after time” etc. etc.
My experience is that if this is your experience, your retrospective is not done right – do it right and get some value from it 🙂
It is very easy to have a meeting with no result; well maybe the team complain, they vent, or talk a bit and then 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 is even valuable to use in our private lives.
Where else do we have the opportunity to take the step back and look at what we have 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: do something actively 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 is what a retrospective is about. Our axes in the IT world are our brains and our process. We need to stop up, so we can reflect and improve; 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 happens.
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.
I am so glad you asked; just keep reading 🙂
How to run a good retrospective?
As I already say: 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 of 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 think about improvements in their daily life. Sadly my experience is that it almost never happens.
There are many other things that can help you make good retrospectives and many different aspects of having one. In this post, I will focus on process and structure.
There are some things that need to be there for a retrospective to be effective:
- Have focus on the process
- Structure the meeting
- End up with action points (and follow up next time you meet)
The Process
It is important that a retrospective focuses on the process. The purpose is to improve your process and learn from what happened from good things and problems.
It is very easy to forget this and to start discussing who is at fault. It is not about the person, it is about the process that you use.
I personally use the Prime Directive to set the stage from the beginning. It has been around for a long time and continues to provide 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.” Norm Kerth
It is 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 put in other terms:
- Getting ready to go.
The most important is to ensure that everyone knows- What the topic of today is
- What the time frame is that will be discussed
- Any particular focus if it exists
- Who is participating
- What the status of the actions points from last time are
- Looking at the information at hand.
What happened since last time? It is important to be as objective as possible. Use whatever artefact that 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 🙂 - 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 the things within your sphere of influence? - 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 maximum 2-3 action points for next time. It is 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). - Last point is about getting ready to leave.
Look at the retrospective;- Did it work?
- Do you need to do something different next time?
- Does everyone know what they agreed on?
- 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:
- Have an external facilitator; it can be someone from the outside or someone from another team
- Make sure there is room for everyone to reflect and to speak
- Create safety for people to speak up
- Have different kinds of retrospectives
- Having different people in the retrospectives like other teams that you work with.
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; many experienced facilitators, including myself, are willing to answer questions on twitter and email.
Good luck on improving your retrospectives – you can do it 🙂
I first wrote this blog post for QED in 2014 in Danish and then in English for Skills Matter in 2019