Most people are aware of the retrospective meeting that is part of the Scrum Framework. It is a key improvement activity used by Agile and Scrum teams at the end of each sprint or iteration. However, people can cause retrospective failure by focusing on speed and only going through the motions.
This past week I was coaching a Scrum team and I witnessed one of the fastest retrospectives ever. The entire meeting lasted 13 minutes and there were 9 participants. Fast? Hell yes! Efficient? Perhaps. Effective? Not even close!
The only thing that would have made the meeting faster was if they had agreed in advance to simply recycle the “what went well” items from the previous sprint and cancel the meeting. (BTW Another one of my teams did exactly that and I think I was less upset. At least they weren’t faking it.)
I get it – we are all super busy. Too busy. We are scurrying around like hyper-caffeinated squirrels, frantically gathering up nuts. We are continually shifting our focus between all the things we want to get done. It’s a little crazy and not sustainable.
We need things to be FAST, or FASTER. Forget the 8 minute Abs, we need 7 minute Abs. Or 1 minute Abs. Three hours for a retrospective??? Crazy – get it done in 30 minutes…or 13.
Yep, we are all addicted to speed. And there are things that should be fast like firetrucks, shots of tequila, Jimmy Johns, and Elon Musk’s Hyperloop high-speed rail.
Other things are better if they are slower and savored, like a nice glass of wine, a sunrise on the beach, or a shoulder rub. The Scrum Retrospective falls more into this latter category; it need not be fast.
It makes me think that I haven’t done a good job as an Agile Coach to help these teams understand the value of the retrospective or even the whole point of the exercise.
It should not be a mindless ceremony that the team does as quickly as possible. The retrospective is a crticial part of continuous process improvement that has it’s roots in the Deming cycle of PLAN – DO – CHECK – ACT.
Teams that blow through the retrospective are missing out on a key opportunity to celebrate their work, improve their tools and processes, and to recognize and affirm each other. And I don’t want to let that happen.
It wasn’t an accident that the founders of Scrum included the retrospective meeting in the sprint; it’s a key part of the Scrum methodology.
Though it is the last Scrum event in a sprint, it wasn’t an afterthought and it wasn’t simply tacked on to an otherwise complete process. It is necessary. It isn’t optional, to be done only if time permits. The Scrum Guide says this about the retrospective event:
“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.”
I love that phrase and the idea of making the team process and practices more “effective and enjoyable”. To me, that is worth investing some team time to do well.
Do a quick gut check of your own retrospective process and application of the Scrum Framework. If you are on a traditional project, when do you have retrospectives and do they help you to improve?
If you are on an Agile project, do you do a retrospective every iteration? At the same time every sprint? Are they effective at helping the team to improve?
Do you think you are getting the most out of your investment in time and energy? Are your team processes getting more effective and enjoyable? If not, perhaps you are not doing it correctly.
I’ve spent a bit of time reflecting and writing about how teams can avoid retrospective failures and increase effectiveness. Here are a few posts that I’ve written that may be of interest.
Please share your comments, feedback, tips and best practices. I am not going to be quick about it, but I hope you will find it effective and enjoyable.