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.

We are in the middle of a pandemic and a highly polarised world at the same time. I think it would be beneficial to reinforce the idea that a team's collective intelligence and productivity in an industrial sense have more to do with individual social sensitivity or emotional quotient as some call it, of its members than their individual brilliance (IQ).
My talk is based on the research in the field of distributed cognition by Edwin Hutchins, the relation of group intelligence to individual social sensitivity by Anita Williams, and the latest research by Nikoleta Et all which suggests that not only is a team's collective intelligence linked to individual EQ but more specifically to least socially sensitive person in the team.
A simple takeaway from this talk would be for everyone to realize that no matter how technically brilliant you are, you perhaps are the reason for your team's low 'collective intelligence' if you have less than the average EQ of your team.

I will also suggest some measures on how to mitigate the EQ issues.

"Quality is everyone's responsibility" has to be one of those phrases which looks great on t-shirts and posters but when put into action, often fails.
There is a funny leadership story which goes like this " There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it"
Therefore assuming that everyone in your team (developers, designers, QEs or analysts) would be instinctively inclined to incorporating quality in their day to day work is a terrible assumption to make.
Quality is everyone's responsibility might be true but it cannot work in isolation, it has to be supplemented with an accountability framework.
In this talk, I am going to present exactly that framework and help people especially leaders - technical and people, implement proactive quality processes in their teams.
The information presented in this talk does not require audience to have any technical knowledge and applies to all the roles.

Mike Cohn advocated writing user stories in a “As a <user> , I want <action> so that <benefit>” template because it put the system requirements in first person, thereby bringing an inherent user perspective to design and helping product owners prioritize effectively. However, the user perspective has so far not captured the user state of mind or mood resulting in terribly designed interfaces and bad user experiences.

Let us look at a couple of user stories to understand this concept.

a. As an entitled-to-support user, I want to enter my broken in-warranty hard disk details so that I can create a support ticket.

b. As a valid user, I want to like my friend’s post so that he gets fake internet karma.

For a development team, these user stories mean fields, buttons, backend, fancy CSS and that is all. But if you look closely, user in story 1 is not just an entitled-to-support user but a ‘frustrated and dejected” user whereas the user in story 2 is a ‘happy’ user.

How about rephrasing the user stories in the experience template

As a <user> , I want <action> so that <benefit> becomes As a <mood> <user> , I want <action> so that <benefit>

Since the purpose of user stories was to initiate and enable team discussions on features and not be the actual task set in stone, I strongly believe that capturing user mood in the story would enable better design discussions and even sharper prioritization.