 Welcome everyone, today's session is going to be taking bias into account why introspective promise more and deliver less. Thank you and hello everyone, my name is Deepak, I am an engineering manager in Red Hat. I am very glad that I could excite you in this session. So about me, I spent five years in PTC, around ten years in Red Hat. I'm from a quality engineering background, but very recently moved into development engineering. And I am from that time when Jira was just a bug tracker. And they had not thought about putting story points in fractional numbers yet. All right, so about today's session, so what I am planning to do is I'm planning to equip you all with some of the thoughts and some of the knowledge which I have, I have read, I have researched about retrospectives. And I think, and I hope that if there is a situation where you have to probably lead or do a retrospective yourself, you can, that knowledge and that information can come handy for you. In a nutshell, today's session is going to be about rethinking retrospectives as we know them. All right, so before we start, I want to make sure that we all are on the same page with respect to definitions of some very common terms, right? So reflection is consideration of some subject matter, idea or purpose, right? For example, let's say, today morning I woke up, I had an argument with my wife. And then, which obviously I lost. And then I went to take a shower in the bathroom. And while taking a shower, I reflected on that argument, right? Without a purpose, right? I don't want to be an improved argument maker so that I can defeat my wife in the future, but just for the sake of it, right? I reflected on it. And so what were the things that I said, probably which I might have said in a better way to probably win that argument or maybe win the fair play award in that argument. But that's pretty much about reflection, where you sit and without any purpose, you reflect on things that happen in the past that matter to you. And then retrospection in our context of agile and everything is reflection in anticipation and with a purpose, right? We buy a process or in anticipation of improving something in the future. We sit and reflect on the past. That's how we do sprint retrospectives as well, right? We have a purpose to improve ourselves for the future sprints or future iterative development. OK, so in, I think, 1983, Donald A. Sean wrote a book called The Reflective Practitioner. The idea was how do people who are great in their jobs do reflection, right? And there is another book by a surgeon called Better. It's not the name of the surgeon. It's the name of the book. I don't remember the name of the author. I think it's Atul Gawande. He also says the same thing. He says that people who are experts in their field, they do a lot of reflection. And how good are they in their field depends on how quickly they get the feedback and how quickly they are able to reflect on that feedback and probably make comments on their future actions. So Dr. Sean divided reflection in two parts, reflection in action, right? So let's say during a football match between Brazil and Argentina, that is an action, right? It has a quick feedback. The result is the feedback, whether it was the win of one of the teams or it was a draw. The result is the feedback. It's a 90-minute window. And if someone is doing reflection inside those 90 minutes, that would be called reflection in action. And once the game is over, let's say Brazil won, and then the Argentinian team sits together with their coach and their staff and then they do a retrospective on what went wrong in this game and how could we beat Brazil in the next game, stuff like that. That would be reflection on action, right, after the event has passed. And when you draw parallels of this approach with working in an iterative development cycle, you'd say that the feedback comes when the software is GA or the feedback comes when you demo your sprint work to your stakeholders, right? And that is exactly when we do our actual retrospective, right, in three weeks or two weeks, whatever time. And then there is another book by this Nobel Prize winner, a psychologist called Daniel Kahneman, called Thinking Fast and Slow. And in this book, Dr. Kahneman says that there are two types of happiness, to be honest. One is in the moment, fleeting feeling, right? And then the second one is once you start reflecting on what happened in the past, right? Think about it. How you feel in your job is very different than how you feel about your job. In most of the developing economies and countries like India, work-life balance has never been a great, what do we call it, hiring incentive, right? Because people want to get into a job. They want to experience the pain, the stress and all of that. As long as they can, after one or two years, sit back and reflect on that job of three years, they know that they have queued a lot. They got promotions, they got good salary increments and all of that. And they started a good career, even after experience. In job, they were slightly unhappy because they were facing those things on a daily basis. But when they reflect on that, they feel very happy and proud that they are queued that. So the thing is that our remembering self always takes 90% of the time, takes all the decisions for us, which some of the times are not in the best interest of ourselves, right? Okay. If you remember this, that's good. This is called Deming's Field or Sheva cycle based on the guru officer, Edward Stemming, who created this in 1950 and all of the iterative development processes and continuous quality improvement processes started with this. Do, check, act and plan. The check part is where modern sprint retrospectives live, right? We do something and then we check how are the results? Did we do something wrong? And then we start acting on those results and we see that, okay, what are the changes that we need to make? But do you think that modern retrospectives work like that? They are rife with boredom, politics and even if you get some action items to work on, they might not be the best action items that your team needed. They are those action items which the most important people in that hierarchy wanted to happen, right? It's not that the team needed it. If you look at the philosophy of Agile, it means that this team has to be autonomous. They have to decide whether we want to, we made these mistakes and we want to improve them. Nobody from outside should tell them that, okay, you made this mistake and now improve it in the next sprint, okay? So John Bain and some of his colleagues in 2002 gave this framework for reflection, right? So whenever you do retrospective, you might be probably using some kind of document where people use that very common template like what went well, what went wrong and what are the things that we can improve in future, right? So if you hand over that document to me, I can clearly tell what is the level of maturity in your retrospective, right? And you can also tell that. So look at these five stages of maturity in retrospectives by John Bain. The first one is, let's say I am a developer participating in a retrospective and I write in the what did not go well section, I wrote that one of the co-developers sat on my code review for three days, which delayed my work, right? So I'm just reporting the incident. I'm not connecting the incident to my experience and feelings and thoughts. I'm not using the incident with my knowledge and everything to tell that, okay, I can understand why this happened and this is how we should be fixing it for the future. So reconstructing part is the topmost level of maturity. So if you look at, let's say there are eight people in the team and they give 20 points on the retro sheet, you can easily map them against these five maturity ratings and tell yourself that, okay, our team is at this maturity level. There are maybe one or two people who are at level five, but most of the team is at level one or two, which is wrong. You don't go to retro to just report the things, right? You go to retro to sit together and use your existing experience to tell, okay, I think this happened due to this thing and we as a team should be fixing it in this manner. Now the very important part, why do we say that we should not do retros at the end? I don't believe in doing retros at the end because of this reason. So there is a thing called recency bias. The book that I showed in last slide, this one, Thinking Fast and Slow, has a very good example of colonoscopy. They experimented that Dr. Kahneman did with two colonoscopy patients. They recorded their pain threshold during the operation. And even though patient A faced more pain collectively and had a longer procedure, but when they were asked to remember the pain, patient B said that he remembered more of the pain because in the last part of his operation was where he faced the most pain in the procedure. We say that we mostly remember whatever happened very recently. It's very common in performance management as well. So as a manager, let's say I have to give an annual bonus to one of my reportees, right? I sit and think about, reflect on what he or she did in last year. My judgment would be fully biased if I have not documented regularly, maybe monthly or every 15 days, or on certain events. If I have not journaled all these things during the year, and I'm just going to sit and reflect on what that person did for one year then assign them a bonus that would be full of recency bias. So I'll probably remember only the latest things and that can be injustice to them. And similar thing happens in retrospectives as well. And hello effect is related to, let's say we did really well in this print. And there was something which was a very minor thing if you ask the team, but for a certain stakeholder, very important person in the hierarchy, it was a major, major thing, right? So one major thing, which was not even a major thing, because it was important to some important person, takes away all the good things that we did. So the whole emphasis is now certainly on that one minor thing in the retrospectivity. So don't let hello effect alter how you think about retrospectives. And then there is lots of small numbers, right? So when we sit together, and I have seen that with mostly the Indian engineers, when we sit together in a retrospective with let's say European and North American engineers, they don't feel empowered enough to speak about the problems that they face. So law of small numbers says that if you choose a very small sample to draw conclusions about a bigger group, you are probably not getting the right indication of what has to be improved, right? And then there is some cost fallacy. Let's say the team together wrote a new logging framework for their software. And now after two or three months, they see that it's not maintainable, it's causing a lot of problems. But they don't want to get rid of it because they are emotionally invested in, because they did a lot of hard work in writing that and all of that stuff, right? So some cost fallacy says that the team is willing to drag that along and probably let their productivity hit. But don't talk about it. They don't want to talk about it because they were somehow emotionally invested in that effort, right? So as a meeting leader or a senior engineer in that meeting, or for everyone else, right, you have to get rid of those things that are not making any meaningful addition to your work. And now the takeaways, I think we just have two minutes. The takeaways, the idea is to retrospect frequently and in the moment. How do we do that? So I had mentioned one very radical idea that why not add one custom field on your tickets if it is Jira, then customize Jira to add a new field called lesson turn, right? So every time you work on a ticket and you feel something bad happened, something happened that was not good, then you go ahead and add something to that. Not in the comments section, maybe in a separate field, right? And once you start in this print and you start retrospecting, you go through those lists, collate all of them, and then think about it. That would mean that you are journaling very regularly. And your retrospecting points are not full of recency bias, right? And then reflection as a technique is a skill that can be taught. I have linked this paper in which Bail and some other researchers did a study on teachers who were learning to teach to young students. And they gave them some daily journaling activity for 30 days. And then they saw that reflection was something which could be improved by training and practice, right? We are not natural at reflection and getting purpose driven action items for future. You have to practice and learn it. And third but very important point, enable fair communication distribution in the team. As soon as you are the senior most person in a retrospecting meeting, if you are, and you see that there are only two people who are dominating and hijacking the whole discussion, then you have to make sure that everyone gets a fair chance in speaking in at least the retrospective meeting. That's very important, both for retrospection as well as for the psychological safety of the team. And I think that's pretty much it. We are at the top of time. So if you want to connect with me, this is my Twitter ID and my LinkedIn ID. In Twitter, I usually do the humor stuff. You can see a screenshot here. And in LinkedIn, I usually do the serious stuff. So yeah. Thank you, everyone.