Sprint retrospectives were designed to make the process of software development empirical. An approach where you can make mistakes but also reflect and learn from those mistakes.

They possibly are the ‘A’ in the Deming’s Wheel (Plan-Do-Check-Adjust) that served as the origin of iterative development methods. Unfortunately, that is not how modern retrospectives work. They are rife with boredom, failure to admit mistakes, and lack of follow up if somehow two or three action items were identified.

My interest in organizational behaviour and keen research links each of these problems to a cognitive bias.

In this talk, I will list all of the biases that make retrospectives ineffective and ways in which we can mitigate them.

For example, Recency bias is the tendency to focus on the most recent time period instead of the entire time period. Having retrospectives at the end of a sprint or maybe once a month makes people forget most of the problems they faced or the mistakes they made early in the sprint.

But how do we fix this?

Radical idea but how about a custom field called “Lessons learned” on every ticket you work on. Everybody keeps filling their observations per ticket during the sprint instead of waiting for the final retrospective.

We can call them micro-retrospectives spread across the entire cycle that can be the fodder for the actual retro meeting.

There are also other biases like sunk cost fallacy and halo effect that I am going to discuss in this session.