I love a good retro. It gives you an opportunity to vent, de-stress after a sprint, raise concerns but also for praise and motivation ready for the next sprint. A friendly platform for open, honest and frank discussions.
But what about the venting? The frustration? Those things in your project or amongst your team that cause issues. Those hindrances that we complacently acknowledge as “just the way it is” or “nothing we can do about that for now, but we will do later…”. Most of the time they keep reappearing retro after retro, with little or no attention given to them. So what can we do about them? If all we do is complain for an hour or so every 2 weeks how is that productive?
The step that frequently seems missing to me in a retro is to collate the list of woes that have hindered the sprint, and to do something about them. I’ve been in Retros like this: We collate the obstacles from a Sprint; we make a list of actions; but they’re rarely actioned. They infrequently leave the whiteboard they’re written on, or at best they’re noted down in Confluence and never looked at again. Nothing more than a remnant of good intentions.
Don’t finish the retro until you have a list of actions. A popular method for defining meaningful actions follows this criteria: Specific; Measurable; Attainable; Realistic; and Timely. Having SMART actions provide quantifiable feedback that can motivate your team to engage with them. These criteria can be broken down into the following:
- Specific and Measurable – An action needs to be tangible, whose progress can be tracked so teams can feel a sense of achievement about working towards correcting issues.
- Attainable and Realistic – If it isn’t then the team won’t be motivated to achieve it. You want people to be engaged in working towards the action so they don’t get ignored (and you’re no better off than you started)
- Timely – needs to be something that can be accomplished before the next Retro, so its success can be realised quickly. Also prevents the actions from perpetuating (in the same way we keep stories small and focused)
For the things that go well during a Sprint… well we don’t need to do anything about those… do we? Absolutely not! Things that go well in a sprint should be praised, but we should take action to ensure that those things continue to happen. This isn’t always necessary for every positive, but sometimes you need to keep on top of them… you can’t have too much of a good thing!
But how do you encourage and enable the team to take ownership of these actions? They can be ignored because “someone else will do it” or “didn’t realise it was on me”. People on the team can’t justify complaining about things if they don’t take ownership. Admittedly there are external factors that are outside the control of the team, but this alone warrants its own blog (and even these can be mitigated to some extent).
So this is what I’m proposing – have them visible as sprint goals, maybe on a whiteboard close to the team so they’re constantly reminded of them. Alternatively track them the same way we track everything else in a Sprint – as a story or ticket so they’re no less significant than anything else. Sometimes this may not be possible, given the client or the nature of the actions, so use your judgement to determine how best to track them. Their importance needs to be realised, to a greater extent than what they currently are.
I’m currently trying the whiteboard trick in my team’s Sprints, so I’ll try to feedback on how well this goes. Give it a go yourself and share your experience!
