Deepak Koul

Title : Taking biases into account : Why retrospectives promise more and deliver less 

Abstract : 

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 behavior and keen research links each of these problems to a cognitive bias. 

In this talk I am going to 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 of 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 what 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. 

This way we have smaller micro-retrospectives spread across the entire cycle that can be the fodder for actual retro meeting and also help us keep clear of  the recency bias.