No time for Retrospectives?
Here’s what to do about it
Arguably the most important meeting for agile teams — or teams-of-teams — is the Retrospective. The process of reviewing the team’s data, drawing conclusions — or better still, creating hypotheses — and acting on them is the most typical process by which agile teams improve their processes, their teamwork and their performance.
Books have been written about how to conduct them, and make them interesting and productive.
So why is it that this is the first meeting many teams abandon, or choose not to hold at all?
I have heard a few reasons, but typical among these is “we just don’t have time”. Now, you and I both know that’s not the problem, right? But that’s what we tell ourselves when we are prioritising other things. If a team is not doing retrospectives, it simply means they value other things more — pretty much everything, in fact.
I can understand why a team might be reluctant to invest 90 minutes or so in a meeting in which team members are encouraged to raise all the niggling things that have gone well or not so well for them over the last couple of weeks — or that made them feel mad, sad or glad; or was blowing wind in their sails, or whatever — for the sixth meeting in a row.
So, what are we to do?
Here are a few things you can start with:
Ask the powerful question:
Ask the team: “How do you go about improving your performance?”
Their response will give you some insight as to whether they have alternative means of addressing their performance, and what that might be. Or not.
If they respond with: “We don’t. How should we go about it?”, that opens the door to a conversation about investing time in ‘sharpening the axe’.
Review the team norms
Most agile teams have a working agreement — a set of guidelines about how the team operates and behaves, what’s tolerated and what isn’t.
If the team does have such an agreement, suggest reviewing it and asking the team how they go about solving problems and improving the way they work. If not, suggest creating one. You can even facilitate the discussion.
There is a risk, of course, that if a team “doesn’t have time” for retrospectives, they probably won’t have time to create a working agreement either. In that case, be patient, and wait for something to happen that you recognise would normally be addressed in a retrospective. See how they deal with it.
If they don’t, ask what they intend to do about it, whether they have a protocol for making decisions and solving problems.
Ensure actions get Done
If nothing ever changes as a result of a retrospective, I wouldn’t turn up to one either.
I have seen many teams get quite good at holding retrospective meetings, but fail to translate actions agreed at the meeting into actual progress.
Firstly, never select more than 3 actions. If you are new to retrospectives, or the team is reluctant to spend much time in them, select just one. But make absolutely sure that someone actually completes it. Seeing problems being resolved, more than anything else, convinces people to attend next time, and that the meetings are worthwhile.
I advocate putting them on the sprint backlog along with all the team’s other work. If you are doing Scrum, you can even estimate them (in story points, if you must) and count them towards the team’s planned velocity.
Just make sure that they are not prioritised below everything else. Improvements to the way a team works — improving their effectiveness — is ‘real work’
Do little ones instead
On the rare occasion when a team genuinely doesn’t want to invest the time to do retrospectives ‘properly’, i.e. thoroughly, there is another option.
If you observe that the team ignores problems, or obvious performance issues, try to get the team to address just one the next time it occurs.
If you see, for example, that the defect count is rising, bring this to their attention, and coach them to find possible causes, options to address it and actionable experiments. This need not take as long as a formatted retrospective, but it can certainly start to change the team culture. Suggest that next time someone spots something that should be improved, bring it to the daily meeting and decide then who will be involved in finding a solution. The problem-solving can then go on in the background, while the rest of the team carries on with the ‘real work’ ;-)
Try whichever of these you think will help.
