Like many agile based teams we regularly run retrospectives to gauge as a team how we are going and think of what and how to improve.
We have one every two weeks, they are time boxed to one hour and are held standing up (like we do for nearly all of our team meetings).
We have the typical ‘happy’ column, a ‘sad’ column and a ‘puzzling’ column. Everyone brainstorms on post-its, we group it together and vote on what we would like to discuss.
The team is prompted by being next to our wall and running through some of the achievements/big events in the past two weeks.
I ask probing questions such as:
- What has slowed down your progress?
- What has enabled you?
- From when you pick up a story to when you deploy it to production, what obstacles do you have?
- What areas have been inefficient and where is there unnecessary work or rework?
There is one key part that distinguishes a productive retrospective from a time waster - the actions and improvements that are an output of the retro.
One thing that is tempting is to discuss the particular details of an issue that has just occurred - which can often turn into a bit of a whinge and sometimes even a blame game (especially if the people involved are not present at the retro). Then a tactical action is thought of to address the latest symptom and the team moves on to the next highest voted item.
It is far more valuable for the team to discuss the patterns and root cause of the issue.
To do this, the team should discuss what process was followed and give other examples of that process in play. This is to remove the emotion and raise it up to a more high level discussion about repeatable systemic issues.
Once we understand the root cause we explore what is within our control to improve. That way, when we begin to think of actions to improve the situation we are thinking of changes/tweaks to our process rather than a quick fix or bandaid.
Then, once we have an action to improve our process, we run through a few hypothetical situations to ensure we have a shared understanding of what our new improvement looks like. We’ll often look at a few tasks in our backlog to give us some examples and we run through how things will play out with our new improvement.
The next retrospective the first thing we discuss are our actions from the last retro:
- Has the action been implemented? if not, why not?
- Is the issue still occurring? if yes, why?
- Did the action improve the issue? if not, why not?
By beginning our retrospective with the previously agreed actions, it reinforces to the team the purpose of our retrospectives, which is, to share examples of our teams anchors and engines, to discuss their root cause and to action improvements to our process.