Great retrospectives are all about asking the right questions and collecting the right amount of information. Retrospectives are a waste of time if the team conducting them is not committed to acting on what they uncover.
Retrospectives are often used in software development to take a look backwards at what went well and what didn’t go well so that future releases can be better–that’s the theory at least. Retrospectives are common in Agile software development and they are useful for life in general. Some productivity gurus suggest doing a mini-retrospective at the end of each day.
Why Are You Asking the Questions?
When thinking about what questions you want to ask at a retrospective, think about what you really want to know at the end and what you will realistically do with what you find. If nothing is actually going to change or be different after the retrospective, they aren’t worth doing. Sure, it feels good to vent and talk about all the things that didn’t go well, but in the end it is more demoralizing to stir up all those bad memories and then do nothing about them.
On one project I stopped doing them for this very reason. The retrospective meeting was packed and the ideas flowed in about what had gone well and what didn’t. In the follow-up meetings people were less attentive. When it came time to assigning names and next actions to the things people had previously said needed to change, few people volunteered. I spent the next few project meetings flailing about trying to get owners for these tasks, but nobody was willing to own them. Eventually I dropped the topic all together. At the end of it all, I’d spent a couple of days of time (all combined), preparing for the retrospective, having the meeting, organizing the data collected, and then following up, with very little to show for my time.
Is the Team Too Big?
I’ve seen retrospectives launched with slide decks of 30 pages or more. It may seem more efficient to collect information in advance over a mailing list, put it into a slide deck, and then discuss it all at once, but that misses what comes from the conversation. Synergistic magic has a better chance of happening in real time, collaborative discussions where everyone starts from scratch. If starting with a slide deck is what it takes to orchestrate a retrospective, the project team is too large.
That’s not to say there might not be lots of good information packed into that deck, but way more than could ever be actionable or that everyone could wrap their heads around. If you can’t or won’t do much with what you collect, don’t waste everyone’s time collecting it. If you really think you’ll action all those issues some day, you aren’t living in reality. The next retrospective will turn up another pile of issues and the important ones will show up again.
Retrospective Questions
Here are the questions I like to use. I ask them in real time and since we work in geographically distributed teams I use Etherpad to collect the results.
1) What went well?
2) What didn’t go well?
3) What would we want to focus on improving in the future?
4) What are TWO things that we will specifically work on doing differently in the next release and what will we do to ensure that they happen?
Question number three typically generates answers from question number two and question number four typically generates answers from number three.
If focusing on two improvements for the team is a drop in the ocean (two small to show any significant improvement), it’s probably useful to bucket the targeted improvements to each functional team or a grouping that makes more sense.
Only Two Improvements?
Selecting two things to achieve next (as the outcome of the retrospective) is all about building positive project psychology. By that I mean, the positive sense that the project team can and will achieve the goals they set. It is demoralizing to look at a huge list of things to do, attempt to do a whole bunch of them, and then fail at achieving most of them. Once you knock two off the list there is a sense of accomplishment and success and if you picked the right ones you should see the benefits in the next release.
If two improvements don’t put a dent in improving your releases your project might not be releasing often enough or it might be too large.
You Tell Me
What are your favorite questions or techniques for productive and meaningful retrospectives?
2 Pingbacks