In this post, I would like to describe why agile retrospectives are important, and some cognitive biases that might make your retrospectives less effective.
Retrospectives are important for many reasons. For me the most important reason is retrospectives are what made humans thrive. By definition, retrospectives are about imagination: Our ancestors built survival tools by retrospecting. We innovate by retrospecting too. Retrospectives answer the question “What would have happened, if X had been this way or that way?”. We can’t answer this question, because we can’t go back in time and change X and observe the results. However we can imagine the possible outcomes. This ability of imagining something that doesn’t exist (gods, money, other innovative tools) is one of the things that made us humans different. I believe this is a very good justification for why we need retrospectives and why they are important. I’m inspired by the Book of Why by Pearl et al. to write this paragraph, and I highly recommend this book if you’re interested more in modelling human reasoning.
I once asked a friend of mine if they followed any agile retrospective processes at work. His answer was “no, we don’t need it because we’re very small”. I thought fair enough, but I couldn’t understand how this would make them insusceptible to cognitive biases. It turns out they do suffer from biases, the fact that they are a small team does not make them immune to biases. Here I’m specifically thinking about i) anchoring bias ii) recency bias iii) fear of being put on the spot.
Anchoring bias manifests itself when someone does something for the first time, and the observers get “anchored” by this first behaviour. For example, when negotiating a price, the first offer sets the anchor and the rest of the negotiation continues around this first anchor. In retrospective meetings, anchoring happens when someone first retrospects about how the past sprint went openly. Then the observers’ thoughts get anchored around this first retrospection.
Recency bias can happen (it usually does) when participants are immediately and synchronously asked to retrospect at the time of the retrospective meeting. A better approach is to keep a feedback session open for some time (e.g. during a project iteration) so that people can provide feedback and retrospect as thoughts come to them without being rushed.
Last but certainly not least, retrospections and feedback submissions should be done anonymously so that people feel comfortable submitting potentially arguable things without the fear of being put on the spot. This is necessary for really useful feedback, otherwise you might find that in your retros people say only nice things and avoid talking about real issues. It might be necessary though to remind people that this is no reason to get personal or be negative or rude. This is why for good retrospectives, you must first have a good team culture, otherwise I personally find that retrospectives can do more harm than good.
To address the cognitive biases described above, my friend and I built RetroBox a Slack app for facilitating agile retrospectives. We noticed that many teams underestimate the value of good retrospectives or they don’t know how some good practices can increase the value they get out of retrospectives.
Retrospectives aren’t as easy as one may think, there is a lot of things that each of us is probably doing wrong. For example, do you do security checks before you start your retrospectives? Do you take actionable items after retrospection? Does your culture allow you to have comfortable retrospectives?
We’re a team of two devs, and there are a lot of things we would like to improve. But we use RetroBox in our daily jobs, and we still find it useful in our workflow, and we hope you find it useful too.
Emre @ RetroBox
