If you think retrospectives have lost their shine, why not run a retrospective on your retrospectives? Look back at the good ones, and the less inspiring ones, what might you not have tried yet?
Many years ago, when I experienced my first retrospective it was mind-blowing for me. It was so different to the old project post-mortems and autopsies I had seen before. We were taught a structure that was revolutionary to us. We were invited to find examples of 4 types of insight from the last month’s worth of work. See below:
Suddenly things shifted from “who is the weakest link?” or “who is going to take the blame/ credit?” to something more constructive.
Word spread...other teams started noticing that we weren’t dreading our meetings. We seemed to be improving. Others started using this ground-breaking structure and, of course, it worked for us so why would we stop using it?
Fast forward about 12 months and a terrible decision was made, albeit a decision that had good intentions. It was decided that all teams should have retrospectives and that this was the structure they should use. Laminated, company-branded templates were created and shipped out to project managers (who were expected to be Scrum Masters) all over the organisation and they were expected to be used. Indeed it became part of the objectives of the individuals, teams and projects.
It had the same effect as trying to force people to have fun!
Regardless of the mandatory nature of it (people will resist almost anything if they feel they are being forced to do it) simply the repetitive nature of it was bad enough.
There was so little thought to a retrospective now that people didn’t even bother writing the words on the flip chart/whiteboard...they just drew some symbols...
We found that engagement dropped, attendance dropped, improvement stalled, and finally teams stopped getting value from these meetings.
Something was wrong and it upset me because I had seen how valuable these sessions could be. It took some experiments to find out what is probably obvious to you. Namely that if you ask the same questions you typically get the same answers. That, and people get bored easily.
So we tried a few different structures, we asked different questions, we had retrospectives that focussed on specific topics, we changed the venue, we played some games, we spent some sessions doing things instead of talking about them (hackathons, prototyping, backlog refinement) and suddenly things were getting better again.
This love of retrospectives and frustration that other teams and other organisations found themselves in a funk of repetition inspired me to design some tools that could help. I published my top tips for retrospectives, Paul Goddard and I created a new structure (THEMED) - check out my YouTube channel - and I created my Retrospective Coaching Cards to try and give ScrumMasters, coaches and teams more options in their toolbox to get the most out of retrospectives.
Retrospectives are my favourite part of the agile approach because they embody the ‘inspect and adapt’ process.
Start where you are, work out what to solidify and how to get better. I have yet to find a team that is so bad that they have nothing good to keep and build on. Equally I have yet to find a team that has no opportunity to improve. Therefore I have yet to find a team that cannot benefit from retrospectives.
If you think retrospectives have lost their shine, why not run a retrospective on your retrospectives? Look back at the good ones, and the less inspiring ones, what might you not have tried yet? Perhaps you need a little inspiration to break the monotony, that’s all.
Check out Retr-o-Mat, TastyCupcakes.org and of course my YouTube channel for a few ideas to start you off.
Geoff Watts is an agile and leadership coach, the author of 3 books and international speaker. You can find out more at his website www.inspectandadapt.com
What can you actually do to make effective retro a reality? The good news is, it’s not as difficult as you might think. We’ve broken it down into 5 elements to make it as easy as possible to massively improve your sprint retrospectives.
Most engineering managers instinctively think of productivity as complex processes like workflows, solutions, and deliverables expressed in purely quantitative terms. The result is a dynamic that’s usually counterproductive. But there is another way.
Often that dynamic plays out in metrics and misguided attempts at fostering engineer productivity, usually by measuring the wrong things and offering the wrong incentives. Fortunately, there are better ways to use metrics to genuinely empower engineers to accomplish more.