#22 - How to Facilitate Great Retrospectives - Aino Vonge Corry

Episode Introduction [00:00:49]

Henry Suryawirawan: [00:00:49] Hey, everyone. Welcome to another new episode of the Tech Lead Journal with me your host Henry Suryawirawan. Thanks for tuning in and spending your time with me today listening to this episode. If you’re new to the show, a warm welcome to all of you, and I hope to have you as a frequent listener to the show. If you haven’t joined any of the Tech Lead Journal social media channels, I’d like to invite you to join us on LinkedIn, Twitter, or Instagram, and you can find the links to those channels in the show notes. Make sure to also subscribe and follow the show on your favorite podcast app. Tech Lead Journal is available on all major podcast apps, such as Spotify, Apple Podcasts, Google Podcasts, and many more. Tech Lead Journal is also available on YouTube with a number of additional playlists that include: episode short clip, patron messages, and the 3 Tech Lead Wisdom that I’ve always asked to all my amazing guests at the end of each episode. Make sure to subscribe to the YouTube channel to get notified for any new videos that I upload to the channel. And if you’d like to support me and contribute to the production of each episode, you can join us as a patron by visiting techleadjournal.dev/patron, and you can help me to achieve the goals that I’m currently running for the show.

For today’s episode, I’m very happy to share my in-depth conversation with Aino Corry. Aino is the author of the recent “Retrospectives Antipatterns” book. And she has a lot of experience in doing facilitation for the past 15 years. Her book describes the antipatterns and mistakes that she has made from facilitating many retrospectives in her career, and what we can learn to avoid those antipatterns and mistakes. In this episode, we had a deep discussion about retrospectives and what we should pay attention to in order to facilitate a great retrospective, which ranges from the elements of a good retrospective, the importance of retrospective Prime Directive, cultivating trust, facilitation skills, and how to come up with good retrospective outcomes. Aino also shared her interesting story on how she ended up writing “Retrospectives Antipatterns”, and what we can learn from her experience, especially for those of you aspiring book authors. In the spirit of the new year, towards the end, Aino shared some of her insights on how we can use retrospective to apply in our personal lives. And if you haven’t done any retrospective lately, including retrospective for the year 2020, either individually, or as a family, as a team, or even as a whole company, I would highly encourage you to listen to this episode and learn from Aino’s sharing and insights in order to benefit from a more effective and productive retrospective.

I hope that you will enjoy this great episode. Please consider helping the show in the smallest possible way, by leaving me a rating and review on Apple Podcasts and other podcast apps that allow you to do so. Those ratings and reviews are one of the best ways to get this podcast to reach more listeners, and hopefully the show gets featured on the podcast platform. I’m also looking forward to hearing any comments and feedback on the social media, or you can also directly send to me at techleadjournal.dev/feedback. So let’s get the episode started right after our sponsor message.

Introduction [00:04:43]

Henry Suryawirawan: [00:04:43] Welcome everybody to another episode of the Tech Lead Journal. Today, I’m so happy to see one of the authors that I recently bumped, with her new book called “Retrospectives Antipatterns”. Her name is Aino Corry. She’s living in Denmark currently. So I’m also excited to have another guest from Europe, which is quite rare for me as well. So today we’ll be talking a lot about retrospectives, which with the current end-of-year, I guess, all of us would probably be looking back on what we did in 2020. And hopefully we can get a good retrospective either with your team, with your company, or even individually. So Aino, thanks again for being on the show. I’m so excited to have the talk with you today.

Aino Corry: [00:05:21] Thank you for inviting me, Henry. I’m very excited to be here.

Career Journey [00:05:24]

Henry Suryawirawan: [00:05:24] So Aino, I know you have a very long career journey. But as a custom in this show, it will be great to share some of your highlights in your career journey and maybe major turning points that lead you up to what you’re doing now.

Aino Corry: [00:05:35] Yeah, I’ll start from the very beginning. Why computer science at all? I started university in 1991 to study mathematics. I did not really know what a computer was at the time. I had never programmed before. But I really was intrigued by mathematics. So I started studying mathematics, but at university where I studied mathematics, you had to take a minor as well as a different course. Computer science was the one which would give me the most mathematics. So I chose that one without really knowing what it was. So we started off directly with procedural programming and the university created language called Trine. And at the first three months of the lectures, I didn’t understand anything. So I stopped going to the lectures, and I didn’t do any homework or anything like that. And then some of my course members said to me, “Well, if you don’t learn how to program now, Aino, you’re going to fail the exam in the summer.” And then they dragged me down to the basement where the computers were, and then they taught me how to program. It was an epic moment. It was fantastic. I really enjoyed programming. I liked the power. I liked the satisfaction. I liked the problem solving. I liked being almost a detective when you needed to find a bug. I really like concentration and being in the flow. So I switched to a major in computer science. My point with studying math was to teach mathematics at high school because I thought that so many teachers teaching mathematics at high school were aiming with their examples and their explanations towards the men in the room and not the women. So I wanted to change that and to make a more diverse education in mathematics.

But then at the very end, when I was creating my master thesis with my friend, Ellen, it suddenly struck me that this would all have to end. And I really enjoyed making the master’s thesis. It was about design patterns, which was new at the time and development of object-oriented language constructs, which was also fairly new at the time. So I decided to apply for a PhD because I didn’t want it to end. And then I got accepted and my friend also had her PhD proposal accepted. So I did a PhD without really knowing what I wanted, but then I thought, “Well, I’ll probably just stay.” And I got a job at the end as an assistant professor. But then I taught a bit for a company in industry while I did my PhD to get some more money because I already had a child at that time. Then they asked me to talk to them, and they offered me a job which would pay me twice as much as the assistant professorship I already had, which was very difficult to say no to, since I’d been studying for 10 years, and I had a child, and I wanted to have one more child. So I thought this would be interesting. And I worked there for a few years, did some programming, but got more and more into creating conferences, IT conferences, started with a conference called JAOO about Java and Object Orientation in Denmark. And that later became the GOTO conference, which inspired the YOW! Conferences in Asia and Australia. Anyway, I worked there for a few years. And then the university had a new EU project where they needed somebody who was researching software architecture. And with my patterns work, I’ve been working with software architecture patterns as well. So they headhunted me back to university. Well, of course the salary went down, but I was also a bit stressed because it turned out I was pregnant again. So I needed a more calm job, and I got that at university. So I worked there for a few years.

Then I was contacted by my old company again, and they asked me if I could come back. And then I decided to come back to that company because I really liked teaching at university, and I really liked doing the actual research, but I hated writing the papers. I really detested writing. So I went back to industry again, worked there for a few years. And then the university called me again, because now they needed somebody to do research on how to teach computer science because they needed to change the way that they taught computer science at my old university. And I thought, “Oh, this sounds interesting as well.” So I quit the job again. They laughed at me and said, “You’ll probably come back in a few years.” I said, “Never.” And I went to university to study how to teach computer science and how brains learn, which was very interesting. And I started teaching the teachers, the professors, how to teach computer science. And I noticed that some of them listened and some of them didn’t listen. But the ones that almost always listened were the new teachers, the PhD students, who are about to start teaching, and some of the normal students who were TA (Teaching Assistants) . They were really interested in learning how to become good teachers, because it’s a daunting job. It’s really difficult. It’s a great challenge if you don’t know what you’re doing. And then, the old company asked me if I wanted to come back and help them out with some conferences again. And I said, “Yes, I’ll help you out in my spare time.” But then I suddenly had too much work, and then I didn’t know whether to stay at university or whether to go back to that company again, because I knew they would laugh at me.

But then I decided, I can start my own company. And then I can work for the university and for industry, so I did that. I’m sort of doing the same as I did back then, in the sense that I’m teaching teachers at computer science, how to teach computer science, based on my 18 years of teaching computer science and academia in industry. And I’m also teaching in industry, but there I’m teaching Agile development and retrospective facilitation. And I’m an Agile coach for DevOps teams and for developer teams. I sometimes also facilitate architecture workshops where we review the architecture, where we find the hotspots to work on. So I’m still working both places and I still get inspired by both places. I think the teaching has been the red thread through it all. But now I’ve done from being very technical, to being very much interested in how people communicate and work together.

Teaching the Teachers [00:10:57]

Henry Suryawirawan: [00:10:57] Wow, thanks for sharing that. It’s a very interesting story, like the coming back and forth between academia and industry. That’s really interesting. So one question that I have from your sharing just now is that why do you need to teach teachers how to teach computer science? To me, that is very interesting to know about.

Aino Corry: [00:11:16] Well, in 98, when I started my PhD, in Denmark, part of the PhD you get paid for was teaching at the university as a TA, and I was just thrown into it. And I was told, “Well, you’ll teach these 20 young men.” It happened to be only men. Surprise, surprise! Teach them algorithms and data structures and time complexity. And I mean, I had that course seven years before, but I hadn’t really focused on that. So I didn’t feel like an Oracle. I didn’t feel they could ask me anything. I spend a lot of time reading up on it and really doing my best. It was super stressful. Because in my head at the time, a teacher was somebody who knew the answer to all the questions, who never lost their head, who were always calm and always willing to give a little extra time to the students. So I found that very stressful, and that I felt it was like being thrown to the lions, really. But, I mean, I must’ve done well because three of the students in that class started working for Google later, and I actually married one of them. So I must have been an okay teacher. I really think that teaching is a skill, which is different than just knowing what you’re teaching in. It’s not enough to be good at what you’re teaching in. And actually my experience is that sometimes if you’re very good at what you’re teaching in, it can be even harder to teach. Because if you think of the Dreyfus’ levels of expertise, you start with being a novice, and you end with being an expert. The experts have a knowledge of what they do, that’s almost intuitive. So it can be very difficult for them to explain to people who are on different levels of expertise, what this is about. As a teacher, you have to be able to go down to all levels like novice or beginner, intermediate, because if you’re not able to go down to where they are, it’s very difficult to explain the next step to them.

So as the Danish philosopher, Kierkegaard said, “If you want to take somebody somewhere, you first have to find out where they are.” And I think that’s very important in teaching as well that you need to figure out what’s in their head. What are their misunderstandings? What are they struggling with? Why are they struggling with it? I had some teachers at university who would just laugh if there was something I didn’t understand, which meant that I didn’t ask any questions. I didn’t show where I was. And it was not until the exam I got graded. I really wanted to change that. And that’s been my hope and dream all my life; that I wanted to change teaching to the better. First in elementary school, then at high school, then at university. So it’s the same all over. I want to improve the teaching.

Metadeveloper [00:13:43]

Henry Suryawirawan: [00:13:43] I also noticed the name of your company now, Metadeveloper. I’m sure it has something to do about improving the developers itself, not just to write code, but maybe about personality or maybe attitude or anything that you can share. What Metadeveloper are doing towards developers?

Aino Corry: [00:13:59] Yeah. So it was actually my brother’s idea. When I was starting my company, I think 12 years ago, I had that conversation with my brothers about what should I call my company? I could call it “Aino”, some people call their company the name of themselves. Then one of my brothers suggested what about Metadeveloper? Because you’re not a developer, but you’re developing developers. Because you’re creating IT conferences that develop developers. You’re teaching computer science. And at that point I wasn’t teaching how to teach, but you’re teaching computer science. And then you are also facilitating meetings. So you’re just developing developers. So Metadeveloper is very good. But then, I went to America at a point, and they thought it meant “I met a developer”, like I met somebody, but that’s also true in a sense, but that’s not the point of it. So that’s why it’s Metadeveloper

Henry Suryawirawan: [00:14:42] Yeah. Okay. I didn’t see it as “met a developer”. But I mean, yeah. Now that you say it, I could see it as well.

Retrospective [00:14:48]

Henry Suryawirawan: [00:14:48] Alright. So Aino, let’s go to the retrospective, which is something you are very expert in. I think most people these days should know about Agile. Maybe you can help to refresh all our minds here. What is a retrospective?

Aino Corry: [00:15:01] Yeah. So a retrospective is a time set aside where you are looking at what has happened, you’re appreciating what happened, and you’re learning from what happened. And then you improve the ways of how you’re doing things. And the retrospective in development is something that came in with Agile. Well, it actually came in before Agile development, but then it was called, first, a postmortem where after the project is done, after one or two years of working on a project, you had a post-mortem to understand what happened after the project is dead, so to speak, to learn from that. And I know that some companies still have postmortems where if there’s a fault in the system, they make a postmortem and they publish it publicly, either in the organization or outside the organization even, to let other people learn from that as well. A retrospective, Norman Kerth started calling it that and it’s because post-mortem sounds morbid. But a retrospective just means looking back.

When Agile came, you can say that Agile in its core sense, to me at least, is “inspect and adapt”. So that’s the point of Agile, to always figure out where you are and to adapt your direction to that. And then Diana Larsen and Esther Derby created the book “Agile Retrospectives”, and that book is great for everybody doing Agile development, who wants to do retrospectives because it really explains quite succinctly what a retrospective is, why you have them, and also give some very concrete helping descriptions on different kinds of retrospectives, with agenda examples and what materials you need and how long time the different activities take. So it’s brilliant for people working with Agile.

Postmortem [00:16:31]

Henry Suryawirawan: [00:16:31] So you mentioned about postmortem, right? Initially, in the beginning, why people called it postmortem? If you know the history.

Aino Corry: [00:16:38] Well, there were a lot of IT projects that died, that actually you spent one or two years working on them, and then they never amounted to anything. They just died and people try to forget that they invested all this money in them. In those cases, what they found was it would probably be a good idea to learn from this and to figure out “how can we avoid doing this later on”. But the problem was that when you did those postmortems, people had been really stressed and some of them had had divorces or psychological problems. Some of them broke down at the postmortem, showing that it’s simply too late to look at that now. In my brain, having regular retrospectives, and with regular, I mean, every two or three weeks in the team, it’s a bit like when you want to run a marathon. You can either not do anything and then suddenly run a marathon. You can probably pull through it with some breaks and stuff, but you’ll feel very bad afterwards because you’ve probably strained the muscle or you misused a joint or something like that. But if you train every two or three times a week for half a year, then you can do the marathon run, and then it will be pleasant even afterwards. Okay. You’ll be tired, because it’s work, but you won’t have broken anything, normally. So I see the retrospective as a way to avoid becoming completely broken and to catch in time the small problems that you need to adapt to.

Elements of Good Retrospective [00:17:56]

Henry Suryawirawan: [00:17:56] What do you think are the elements of a good retrospective?

Aino Corry: [00:18:00] So the different elements of a good retrospective, depends on how you see it. If you see it as agenda-wise, there are the five different stages where you say, first, they’re setting the stage, then gather data, then generate insights, then decide what to do, and then end the retrospective. If you look at these five, you can do it like that vertically, and you set the stage. You say what happened with the action points last time? Did we do them or not? And then have a round of everybody saying something to get them warmed up and get rid of the brain residue. Then you gather data that could be on post-it notes, or you look at burndown chart or regression test results or something like that. Then you generate insights. You look at the causes. Then you decide what to do. There are different ways of deciding, it could be dictatorship, consensus, consent, or democracy, and then you end the retrospective by summing up what happened, why it happened, and what are the action points, and who are responsible for them.

But there are other elements of a good retrospective which are more horizontal, which could be that you have to all agree to have the right mindset before you start, so that it doesn’t become a naming and blaming game. And you also have to have time set aside for it, which is enough for having a good retrospective. Some people say, “Oh, we can pull it off in 30 minutes. We just sit around the table and ask what happened and what we can do better.” And that’s not a retrospective to me because you lose the setting the stage, you lose the generating insights. And I’m sure you lose something in deciding what to do as well. So maybe I should say that I think that a retrospective should be one hour for every week, but sometimes for two weeks, it can be okay with one and a half hours, just because it’s difficult to take two hours every two weeks.

Another thing is that you should try to make people focus on the retrospective. So if you have a retrospective, and some people are sitting with their phones when other people are talking, that’s very disrespectful. So you should say that, well, this is a retrospective where it’s about learning together as a team. So have your focus on everybody else. Of course, if you need to look at your calendar when we’re gathering data to remember when things happened or what happened, then that’s perfectly okay. But when we’re having discussions, you should respect other people and not sit with your computer or your phone open. So these are just some of the things that I think are elements of good retrospective.

Henry Suryawirawan: [00:20:15] So in terms of the size of the people gathering, are there any maximum number of people that you should not have beyond that?

Aino Corry: [00:20:22] Well, that’s a good question. It depends on what you expect to get out of the retrospective. Because to me, a retrospective for a team, a team retrospective that you do regularly, it’s like team building, and it’s about really learning to become a better team. And it’s diving into some details and spending time on learning about those details. In that case, I would say less than 10 people for 1.5 hour retrospective, because you have to think about how many minutes do you have and then divide it by the number of people and think that you also need silent time for writing post-it notes, or for the facilitator to introduce an activity. So I would say up to 10 people for 1.5 hours.

On the other hand, as I said, it depends on what you expect to get out of it. Because a big part of a retrospective is to share experiences. And I once facilitated a retrospective with, I think it was 80 people, and I had an hour. It was people who had worked on a conference. And their only ambition was for them to vent what had happened and to share what hadn’t happened. And then I sent the results to the managers afterwards so that they could get input. It was almost like just asking them in a Google Sheet, but the difference was that they could see what everybody else wrote. So everybody wrote post-it notes, and then we had a walk through where they walked along the really long wall with all the post-it notes, and read what other people had experienced. And then they could add some more post-it notes, or add a +1 to the post-it note if they agreed. But I would say up to 10 for 1.5 hour, otherwise, you don’t have time to really hear what other people are saying.

Henry Suryawirawan: [00:21:50] That’s a good number.

Retrospective Prime Directive [00:21:51]

Henry Suryawirawan: [00:21:51] So, you mentioned earlier about avoiding the blaming game. For people who are aware of it, there is this Prime Directive of retrospective. Could you explain to us what is the Prime Directive of retrospective? Is it actually crucial to always say it before you begin the retrospective?

Aino Corry: [00:22:07] Well, the Prime Directive is something that Norman Kerth wrote in his book, “Project Retrospectives”, and it’s a very long text about truly believing that everybody did the best job he or she could, given the circumstances, the resources in hand, and what they knew at the time. I think it’s really important because if you don’t have the right mindset when you go into a retrospective, and the mindset should be “we’re trying to find faults in the system, not in the people”. Then you can end up having a blaming game, and somebody will feel bad about it. The long wording from Norman Kerth, sometimes I write it on a whiteboard in the room where I have the retrospective, but sometimes I just use my own words. I say it in the beginning, “Remember, this is about finding faults in the system. We’re not pointing fingers at people.” And sometimes if it’s an online retrospective, I write it in the email just with my own words or the real Prime Directive, depending on the kind of group. But some people will find it, " Oh, it’s impossible to truly believe that everybody did the best they could, because I know even I don’t do the best I could, and I know he’s lazy, and she’s stupid." And what I’m saying is that if you enter a retrospective, expecting to be told off or to tell somebody off, then there is not the environment of trust and understanding that you need to have in a retrospective. Because you don’t get people to open up if they are afraid that they’ll be attacked if they do it. This should definitely be a place of safety for people. That’s also why you shouldn’t talk about what happens as a retrospective outside the retrospective, unless you agreed to it, all of you.

Trust in Retrospective [00:23:32]

Henry Suryawirawan: [00:23:32] So this is what I find a little bit tough for a company or a team setting that doesn’t have this trust culture. Like it’s always about hierarchical, blaming from the top. So when the team in such setup wants to do retrospectives, what would you advise for them to do?

Aino Corry: [00:23:48] I’ve facilitated retrospectives in cultures where there’s, as you said, this hierarchical thing. Can I just take a step back and talk a little bit about trust, because I often facilitate retrospectives where I noticed that there is not enough trust in the team based on different things. Normally there is not a culture in the organization to share things that went wrong and to talk about them in a great way, because we’re all accustomed to finding the fault and finding the one who did it. Probably all of us, growing up with parents, have been asked “who started that” or “who broke that vase” or something like that. Since we were children, it’s always been about finding the wrongdoer and I do the same now in my family of five. I asked, “who left that milk out on the table”, instead of trying to find faults in the system. So I don’t always follow the Prime Directive. I especially don’t follow it in my marriage, but that’s a different saga.

So normally when I find a team that lacks trust, I say we can’t solve the trust issue at the retrospective. That’s something we need to do outside the retrospective. And trust is basically relationship and reliability. And if you feel that you can rely on people, if they say what they mean, and if they promise to do something, then they’ll either do it or they’ll let you know if they don’t, then you can rely on them, that’s one part of trust. And another part of trust is the relationship. If you have some sort of relationship with people, it’s easier to trust them. If you think back just for a moment on the people you really trust in your workplace, just do that for a moment. I’m sure you’ll find that you have some sort of relationship with them. There’s something about them personally that you respect and you appreciate. So that’s why these weird questions that you sometimes are asked to answer in the retrospective, “What was your last meal? Or what you’re looking forward to? Or what are you doing in your vacation?”, are crucial for building trust. But that’s something that has to be done outside. And actually, if you can get the management to also admit mistakes and to show that making mistakes is something that we learn from, instead of something that we punish, then that helps.

If you are not able to do that. If you are with a team where you cannot help the trust building outside the retrospective, you have to work with the symptom. It’s always the same. If you can’t solve the problem, you have to work with the symptoms. You have to adapt to the symptoms. And what I do there is I do an online retrospective where they work anonymously. I’ve been using Google Drawings for working anonymously, because then everybody’s just an animal. And it’s very obvious that you can’t see who the others are. So you feel safe in saying things. And I know that some of the other online retrospective ways of doing it, like Retrium, they also have a setting where you can’t see who’s writing what or who’s voting for what? And of course the perfect thing to do would be to solve the trust issue. But if you can’t, then you just have to work with making it work. And I’ve seen retrospective facilitators with different cultures where once you start that anonymity, once they really believe the anonymity, then they start really writing things that are difficult, and they start really venting about the things that they need to vent about. Of course, if you’re only three people in those retrospectives, it’s rather difficult to be anonymous because it’s easy to find out who is who. But as long as you’re more than five, it’s much easier to stay anonymous, and that works. It’s a hack, but it works.

Henry Suryawirawan: [00:26:58] Thanks for sharing the hack. I know sometimes it’s difficult because people work in either like modules, or they handle certain parts of the things, so we can identify easily. Okay, this may be the person writing it.

Role of a Facilitator [00:27:08]

Henry Suryawirawan: [00:27:08] You also mentioned a couple of times that you are doing the facilitation of retrospectives a lot. So tell us more about what is the importance of the role of the facilitator?

Aino Corry: [00:27:19] That’s a crucial role. Unfortunately, a lot of people are facilitating retrospectives without really knowing what they’re doing. It’s a bit like when I started teaching computer science, I did not know how to teach computer science. I knew computer science, but I didn’t know how to convey it. There’s so much about understanding human beings and communication in facilitating that’s important to know. If you’re doing a “in-real-life” retrospective, you really need to be able to read body language either intuitively or you need to learn about it. And that’s to know that even subtle signs, like where are their feet pointing or where the legs pointing, what they’re doing with the arms, can give you telltale signs about who they’re agreeing with, who they’re disagreeing with, whether they want to be somewhere else or whether they’re okay with the situation.

The role for a facilitator is to make everybody feel so good and create such an environment that things can be shared, even the difficult things, and lead them towards a solution. You need to handle the time. You need to have made an agenda with timing so that, okay, if we spent five more minutes with this, I have to leave out this part of the agenda. Or okay, if I can leave out this part, then I can spend more time on this. So you have to be able to read the room, not just the body language, but also what are the discussions. For instance, if you think that all the data that comes up, and gathering data is something that is somebody else’s problem and not the problem of the team, then you have to try to make them aware that a lot of the things they’re talking about are some things they can’t change. So maybe they talk about other things. The role is crucial, and it’s not enough just to know a lot of fun activities, I think actually that’s the least part of it. Myself, I’ve always been very difficult at reading people, and I found it hard to understand when people lied and what people really meant when they said something, because I always take it very concretely. I don’t have a diagnosis on this. People can theorize about that themselves. But I think that’s one of the reasons why I became a good teacher and a good facilitator, because I was never an expert in understanding why people said what they said and what they actually meant. So I had to learn it intellectually, to read body language and to think about, when they say this, what do they actually mean? And I think that’s why I can teach how to teach and teach how to facilitate, because I’ve had to intellectualize “what are they talking about, really?” Because it hasn’t been easy for me to understand.

Henry Suryawirawan: [00:29:33] Could you share maybe some of the resources on how you intellectually learn all these?

Aino Corry: [00:29:39] Yeah. I have a lot of references in my book to books about body language. And I don’t remember them offhand now. I’m sure we can put some links into something in your podcast description. But I think that what has been important for me is that as a young woman, when I noticed that it was so much more difficult for me than for other young women to understand what people actually meant when they said things was that I started, you can call it a little retrospective every night, where I thought back to awkward situations I had with people. And then I thought about what they said and what could they have said, what could they have meant? Because I was always communicating with data. And it occurred to me that sometimes they were communicating with feelings. And I didn’t understand that because I was just trying to convey data and understand their data. And if they were actually communicating with feelings, it would really throw me. It was very difficult. So I think retrospecting over the awkward situations can help you understand other people.

Dealing with Different Cultures [00:30:31]

Henry Suryawirawan: [00:30:31] I also find it difficult sometimes, not just gender men and women, but also cultural setup, like Western versus Asian. Even within Asian, there are different countries with different kind of like the language structure, the cultural norms and things like that. So sometimes it’s very hard to really gauge and understand what people meant when they say something, or they don’t say something, which is also another tricky part. Do you have any comment on that? How do you deal with different cultural issues between different countries? Provided you have worked with distributed teams across the world?

Aino Corry: [00:31:00] Well, yes I have. And I think that what I should’ve done before I started working with culturally different teams was that I should have read up on it. I’m sure there are many good things online. So one of the things that I heard, after the fact, which I use now is that there’s a huge difference in communication patterns between different cultures. And now I’m generalizing terribly, because it’s based on something that I read 10 years ago. I read that in some cultures like the Italian culture, if you have a conversation with somebody, and you let the other one speak out, then that’s considered impolite because you’re not carrying your part of the conversation. You should interrupt them and do something because after a conversation like that, the Italian person will think, “He or she didn’t take any part in the conversation. I had to carry the entire conversation. It was so exhausting.” And the other person might think, “He or she didn’t let me have one word here. It was very annoying and frustrating.”

And then I also heard that with Japanese people. And again, I’m terribly generalizing here and just talk about what I heard. It’s considered polite to think about what people say before you answer something, which I think is a great way of having a communication, which by the way, I personally find very difficult. So if they say something and you immediately respond to that, they find it’s impolite because it shows that you’re not thinking about what they’re saying, apparently you’ve been thinking about what you wanted to say all the time when they were talking, which is probably also true. So I’m trying, when I’m facilitating, to take more of the Japanese way of doing it. So I allow some time after people have said something, to actually think about what they said, but also, as I said before, what they meant. Yeah, that’s one of the things that I learned.

Presence of Managers in Retrospective [00:32:36]

Henry Suryawirawan: [00:32:36] Another thing that is common for me when doing these retrospectives is the question about the presence of the leaders or the managers, or maybe stakeholders in the retrospective. Because sometimes, again, coming back to the trust issue that you mentioned earlier, if the trust is not there, sometimes the presence of the manager can actually bring fear probably for people to actually really reflect and see what is the fault within the system, not really the people. So could you probably share some comments about whether it’s actually necessary to have leaders in the retrospective team setup? Or we should kick them away, you know, do some other retrospectives with them?

Aino Corry: [00:33:09] There’s your answer; kick them away. My rule of thumb is if you can hire or fire, then it’s a no. That being said, again, it’s a team retrospective. And I also worked as a retrospective facilitator in some startups. And in those startups, the management is part of the team because they’re also still programming or doing data analysis or something like that, whatever they did. And then it only makes sense to have them as part of the retrospective, of course. And then there’s all the things in between. If it turns out that the team at every retrospective has problems or issues that relate to management, then they need to solve these issues before they can start working on their own issues. If it seems like those management issues are overarching and overshadowing the things that they could work on together as a team. So sometimes when I notice that at a retrospective and recurring, these are the things that actually the managers should know about and listen to. First, I asked them , “Do you want me to share these things with the manager? I could take these three post-it notes out and show them to the manager, or we could invite the manager to the next retrospective, not at every retrospective, but the next retrospective. They could be part of it.” And if the whole team says “yes” to this, and if you’re worried they won’t answer truly, then you should make an anonymous vote for this as well.

And if you invite the manager to the retrospective, it’s important that the manager has to be part of the retrospective. I’ve had so many managers saying, “Oh, I’m a little bit curious. I won’t say anything. I’ll just sit here in the corner, like a fly on the wall.” And I said, “That’s the worst thing you can do. If you want to be here, you need to share as well. It’s part of creating the trusting environment that everybody shares.” And if the manager’s just sitting there in the corner, staring at them, it doesn’t really work. And I also had some managers who came up to me afterwards asking, “Oh, could I get some of the details because you’re so good at making them talk about different, difficult things. And they never talked to me about difficult things.” And I say, “Well, the reason why they opened up to me is partly because I won’t tell you what they’re saying. I don’t want to say anything.” So I think it’s very much a “it depends” question. But I think it can be healthy from time to time to bring a manager or a stakeholder or somebody else who’s in close communication with the team, or sometimes a representative from another team that they work closely with, or having a bigger retrospective with both teams or something like that. It depends on the situation. But again, (the) short answer is no.

Good Retrospective Outcome [00:35:21]

Henry Suryawirawan: [00:35:21] Another thing that I normally sometimes question as well from doing all these retrospectives, what can be considered as a good outcome of a retrospective? After they’re doing retrospective, everybody’s happy about it. Or is there any action item? Or people are venting their frustrations? So what can be considered as a good outcome?

Aino Corry: [00:35:39] Well, all of the above, really. All the things that you mentioned, they’re really good. To me personally, if I can make them laugh together, that’s a big win. Because I believe that if you’re laughing together, you are in a relationship with each other where you can relax and have a good time together. I think laughing together is a very good clue for a team. So that’s pretty high up on my list is to make them laugh. And I can make them laugh at me because I’m very good at playing a clown. Or we can laugh at a common enemy, the technologies, or something like that. “Oh, it’s acting up again. Oh yeah. Yeah. Okay. Putting that into JIRA will be really easy.” Or something like that. Laughing is important. Of course you need to have, I normally let them out with one, two or three action items or experiments. Because if you don’t come out with some concrete results, some of the people in the team might think that it is worthless. And if you don’t follow up on these things later on, it might even become worthless. Sometimes you come up with some pretty good ideas what to change or how to adapt at the retrospective. But if you don’t follow up on them, if you forget them once you come back to your JIRA board, your backlog, or your Trello board, then it was actually almost a waste of time.

Retrospective Participation [00:36:47]

Henry Suryawirawan: [00:36:47] Right. Another common problem in the retrospective, especially from facilitator point of view, unfortunately I’ve facilitated some of the retrospectives before, is to ensure that everybody actually equally takes part in the conversation. I know we have sometimes the session of thinking by themselves, writing on post-it notes, and things like that. But sometimes it’s also very hard to ask people to speak, to equally take part, or at least comment out what other people are saying. So from your point of view, as a facilitator for so long, how can we ensure that people can equally contribute to the conversation?

Aino Corry: [00:37:18] It’s a big question. One of the things that you have to do is to make a database decision. So I always, when I facilitate a retrospective, I write down the names of everybody who’s there, and I tick off every time they say something unprompted. To make sure that I have a list, I have data to show myself, to remind myself, “Oh, this person has only said one thing in an hour” or something like that. If I notice that there is a problem and it’s not just something in my head, I changed the setting of the retrospective. The worst you can do if you’re facilitating retrospective with some people who are talking a lot, and some people who are talking less, in my booklet called them the loudmouth and the silent one, is to have a plenum discussion. Because the silent ones will just continue to be silent. One important thing to do is to make sure that everybody says something, when you set the stage, when you begin the retrospective, and that’s why I have these questions, to take away the brain residue from the last meeting, but also to make them say something, because if you allow them to be quiet in the beginning, it’s much easier for them to continue to be quiet. To make everybody say something and you can make them answer a very easy question in the beginning.

Then if it was in real life, I would make them work together two-and-two in different discussions or three-and-three, which will make it easier for the silent ones to be allowed to say something. Sometimes put the silent ones together in a pair and the loud mouth together in the pair. Afterwards, normally both of them will come to me and say, “Why did I have to be paired up with this person who talks all the time?” Which means that they, for once, were not able to talk all the time, which I find a bit funny, and we have a conversation about that sometimes. But if it’s online, there are some things that can help you. Of course, you can have the breakout rooms, that can be a bit difficult. But, one thing that I do a lot with the online retrospectives is to have a round robin, to go through my list of names and ask everybody their opinion about something or ask them the same question. It seems to be more socially acceptable to make round robins when it’s an online retrospective than when it’s in real life. So there are different things you can do depending on the setting.

Retrospective Preparation [00:39:12]

Henry Suryawirawan: [00:39:12] And also for those people who come into the retrospectives, I mean, I would say that not everyone sometimes are looking forward to having these retrospectives. Some of them also just be present because they are invited into the retrospective and just play along with everything that the facilitator has provided for them. So the key question here is that how should everyone prepare themselves, before joining and when joining the retrospectives? Are there anything that you would advise people to actually come prepared?

Aino Corry: [00:39:40] I think it’s a good idea to at least remind yourself what happened in the last sprint or whatever you’re reflecting over. Because sometimes I have people coming to retrospectives again and again, and they say, “Oh, I can’t remember two weeks back.” And I silently think in my head, the first thought is, " Well, why didn’t you think about this before you came? Because you knew what we were going to do." And then of course, my second thought based on the prime directive is, “Oh, I should probably remind them next time, the day before to look in their calendar and to see what happened.”, because some people have a difficulty thinking two weeks back. But other than that, I don’t think they should prepare anything.

What I do with people who are reluctant to go to retrospectives is… It’s different things, really. I sometimes ask everybody before I start the retrospective, “What do you expect to get out of the retrospective?” That can be my starting point. And then some people will say, “Ooh, wasting two hours of my precious development time.” To that I answer, “Well, that’s great because if you’ve got so low expectations, it can only surprise you in a positive sense. So that’s great.” So try to take that in a funny way, instead of being personally insulted. If it’s one person in particular, I would probably take them aside, outside the retrospective and ask them, “Okay. So I can see that you’re really good at evaluating the things that we’re doing with the team, I could really use your help.” So make them be a team player with you and say, “The team has decided, or the management has decided that you have to have these retrospectives. And I believe it’s a very good idea to have retrospectives, but since we have to have them, can you help me find a way to improve them for you? Do we need to spend more time on this part or more time on this part?” And then they’ll say, “If we can make it only 15 minutes, then they’ll be fine.” And then you will say, “Well, that doesn’t really work, but perhaps you can help me out. We can make one of these three activities, which one do you think would be great?” And then they’re a team player with you. And then they feel they have a bit of responsibility at the next retrospective, and they’ll probably support this activity a bit more. And you have to think about that grownups are just children with big loans and big feet. If you have a child and you say, “Do you want to go to bed now?” They’ll probably say no. But if you say, “Do you want to go to bed now? Or in five minutes?” Then they have to choose between one of those two. So you just have to give them options where you can appreciate all options. Same goes for salary discussions, but that’s a different, that’s a different point. But if it’s a whole team that finds that retrospectives are a waste of time, you have to ask them why they’re having retrospectives. Because you shouldn’t have retrospectives just to have retrospectives. You should have them because you think it’s worthwhile. Sometimes with a team that suddenly feel they don’t get anything out of it, which can actually be a healthy sign because it means that the retrospectives are going well and they’re working well together.

I have this little book where I write down for each retrospective, what was the agenda, what’s the action points. And then I write all the action points for the last three months or six months down on post-it notes. And then I say, “Well, what about this action point? Did we do that?” “Yes, we did that.” Okay. So it goes in this pile. “And people get the expected result?” “Yes, we did.” What about this? “Oh, but this turned out not to be relevant anymore.” Okay. We put it in the pile called “not relevant anymore”. Then you end up with some action points that were not done, but are still relevant. And for those, normally you can divide them into things that are long-term goals, and that’s why they couldn’t be done because they couldn’t be done in two weeks, so then you need to drill them down. Or it’s the things that the team can’t really do anything about. Maybe they can only influence, maybe it’s in the soup where they don’t have any influence, and they just need to learn how to adapt to it. So if they’re in that soup and they need to adapt, then the action point for this retrospective could be: how do we adapt to this problem that we can’t change? Or if it’s something that’s a long-term goal, then how do we drill it down into smaller goals? Making user stories short enough to go into a sprint or something like that. It’s the same activity.

Retrospective Fatigue [00:43:16]

Henry Suryawirawan: [00:43:16] So my next question, if we have to do this retrospective every week or every two weeks, sometimes depending on the sprint frequency, a lot of times we find, especially if you are doing it the same way over and over again, that could be like a fatigue, right? It’s like a thing that you have been doing all over again. And I found several times that there are facilitators who try to introduce different ways of doing the retrospective. It’s not just, “Okay, what did we do positively or negatively? How can we improve?” And things like that. But they are just fun activities along the way. Is that a common thing to do? Or are there any other ways to actually avoid this kind of retrospective fatigue?

Aino Corry: [00:43:52] The thing with brains is that they demand a lot of energy, and they are always optimizing. So if you ask the same question over and over again, in the end, you’ll get the same answer over and over again. And that’s when the fatigue sets in. So what you need to do is to appreciate that brains are lazy, and then you need to trick them. And that’s why I think changing the activity is a good idea. But it shouldn’t just be the good, the bad and the ugly, what went wrong, what went well, what should we continue doing. You can see a lot of different types of retrospectives was actually the same question that you asked, just with different, funny things like the Christmas retrospectives that are out right now. What do you ask a Santa Claus for? What do you wish for? That’s the same as what should we start doing? And have you been a naughty boy? That’s what you should stop doing, and things like that. It’s a cute way of asking the same questions. So I think it can give you laughs, and I think it’s a good idea. But if you really want to trick the brain, you have to think harder than that. You have to perhaps shift it entirely into a six thinking hats retrospective, where it’s a different way of doing it. Or a future-spective where you’re looking into the future instead of looking at the past. Or it could be a positivity retrospective where you can only talk about strengths and positive things. Or it could be a retrospective where you put them in a different setting, like if you’re out on sea and you had to do this, what would you do? Something like that. Just try something really weird and make their brains think in a different way. And along that line, it can be worthwhile to shift the facilitator. Often it’s always the scrum master who’s the facilitator. But it could be other parts of the team, other team members who were the facilitator or somebody from another team or an external facilitator. So I’m working as an external facilitator for several companies where I just whoop in and facilitate the retrospective sometimes every two weeks, and sometimes only every three months.

Henry Suryawirawan: [00:45:36] Yeah. I also find sometimes if the same person facilitating over and over again, everyone is like, “Oh, okay, here we go again.” And just keep doing the same thing, what the facilitator is doing. Especially if the facilitator is not creative enough to come up with all different types of activities. Sometimes again, it might be a very, very boring kind of activity. That’s from my experience, anyway.

Retrospective Action Items [00:45:54]

Henry Suryawirawan: [00:45:54] So you mentioned a few things about how we can do in terms of the retrospective outcome. Like for example, you mentioned set aside like one to three action items. Maybe categorize them, whether it is a long-term, something that we can do about it. Or if it’s something that we cannot do, how to adapt with it. Also drill down to action items smaller. How can we ensure all these are actually getting done? Maybe how to follow it up? How to actually resolve it?

Aino Corry: [00:46:19] Yeah. So the first thing to do is to not have as many. I sometimes have teams who will say that “All these 9 things. We want to do all these 9 things. It would be stupid now that we came up with these 9 brilliant things, why can’t we do all of them?” But if you take 9 things and you want to do that on top of the work that you also have to do, it’s just too much. And you’re not setting yourself up for success. So try to be mindful about that. I say up to 3 action points for each retrospective. And then you can either put it on a piece of paper and put it in the room of the project. Even though it’s somebody’s responsibility, it should be placed somewhere where everybody can see it. So that somebody should be responsible for making sure that this experiment is being done and to follow up on it. But everybody could help this person to be reminded to do this. It could be on the wall. It could be on the JIRA board, the Trello board, the backlog, wherever. Try to avoid having a specific retrospective folder where you put these action items, because probably people won’t look at them. At least that’s my experience. Put it where your normal work is. And then the facilitator should definitely follow up at the next retrospective and ask what happened here? Did you do it? And what was the outcome of this? Did you get the expected outcome of this or not? And if not, what you think was the reason? Was it the wrong experiment? Was not implemented correctly? What happened? But it’s very important because if you don’t make sure people do that and follow up, then the retrospectives do become a waste of time.

Retrospectives Antipatterns [00:47:41]

Henry Suryawirawan: [00:47:41] Let’s go into why you’re writing this “Retrospectives Antipatterns”. So I know you have been doing this for a long time, and it’s very interesting to actually come up with the antipatterns instead of the patterns, which is also kind of like contradicting in a sense. So can you tell us the reasons why you wrote the book?

Aino Corry: [00:47:58] First, I was asked at a conference to give a short talk, because I used to do these IT conferences and if some of the speakers went sick or something like that, I would jump in and give a presentation. And then they asked me, “Oh, could you do a short talk?” And I said, “Sure. When?” And they said, “In 20 minutes.” And I thought what can I prepare in 20 minutes. Because all my talks at the time were about an hour. And I thought, well, what I can definitely talk about is the mistakes I made when I facilitate retrospectives. And ever since the book “AntiPatterns” by Mowbray and other people, I’ve loved the concept of antipatterns. I spent all of my master’s thesis, most of my PhD, working on patterns and working on implementing patterns afterwards in industry. But antipatterns, I love antipatterns because antipattern is (description of an) experience about what went wrong. How do you notice you’re in this wrong situation, you made the wrong decision with the solution, and how can you get out of it? And sometimes in the antipatterns with the original “AntiPatterns” book, it’s “Oh, so if you’re in this situation, then you can change the code like that, or the architecture like that.” Another situation like “go find another job quickly because this is really a bad situation.” So I’ve always loved antipatterns and thought about, I think about things in patterns and antipatterns. I categorize with my brain. It’s the way that I do things. I think most people do, some more obvious than others, but I do.

And then, so I had these 20 minutes to prepare, and I thought, “Well, I come up with 3 antipatterns: prime directive ignorance, the wheel of fortune, and do it yourself— were the first three. I gave that presentation and people loved it. And I started getting invited to talk about these antipatterns at different meetups and conferences. And I added more and more antipatterns for retrospectives. And some people asked, “Oh, it’s great. Where can we read about this?” And I said, “Well, you can’t really read about it anywhere.” And people kept telling me, “You should write a book about this. You should write blog posts.” As I said, I quit university because I hated writing. So I never thought I would write a book because I’m not very good at it and I hate it. But okay, I started writing a book seven years ago. And then, “Ah, lost interest. And I worked. And people asked me, “Why don’t you write a book?” And I said, “I am writing a book.” “When is it out?” “I don’t know. Maybe never because I hate writing and I’m not very good at it.” But then I kept coming back to it. And then in 2019, I decided, “No, I want to write this book. I want to finish it.” So I cut down on my consultancy and I spent 2019, most of it, finishing the book. And I had at first on Leanpub and then I persuaded Pearson Addison-Wesley to publish it. And then in 2020, my aim was to go around to conferences all over the world to talk about my book and sell my book. So that was bad planning on my half. I should have probably wrote the book in 2020, where I couldn’t do any work anyway. But well, that’s life for you. That’s why I wrote it.

Writing Book Tips [00:50:36]

Henry Suryawirawan: [00:50:36] I actually was interested when you say you didn’t like writing and you have to spend this whole 7 years to finish writing the book. Maybe, what tips would you give aspiring author, maybe I’m one of them, to actually be able to complete writing a book?

Aino Corry: [00:50:49] Some people say you should just write blog posts, which are easier to write because they’re shorter. And you get feedback on those, and then you just tie them together in a book at the end. They’re probably around the same subject, anyway. So that’s how I did my PhD thesis. My dissertation was all the different papers I’ve written, I put those together and then put some texts in between to make it look like I thought it all through. Another thing that I did was something that Daniel North and Simon Brown prompted me to do was to use Leanpub, which is a way where you can publish your book on your own in a lean way. And you can just publish a chapter and a lot of empty chapters, and then you can get feedback from readers. You can start out having the book for free, and then you can make it more and more expensive when it gets bigger. You can see if anybody’s interested in your book. And if they are, it’s rewarding, and it gives you motivation to write more. But also you can ask them, what do you think I should write about now, or did you like this better than this? And then you can get feedback. That will also motivate you to write a bit more. I heard people saying you should just sit down two hours every day and write something. And I’m sure that works for some people. That didn’t work for me. What worked was the motivation from the pressure of people who actually really wanted to read it. That was great. So start talking about your book ideas. Don’t keep it as a secret. I would say that. Yeah.

How to Read the Antipatterns [00:52:06]

Henry Suryawirawan: [00:52:06] Thanks for the tips. So for those readers who want to see and read your books, what can they expect actually? Are they looking in categories of antipatterns like one by one? How should they use them? Can you maybe share how should people read the book?

Aino Corry: [00:52:21] Yeah, the book is aimed for retrospective facilitators with a little bit of experience. But it can be read by people who are starting out facilitating retrospectives as well. I put some info boxes in the book where you can read about explanations of different activities, so explanation of different concepts. And if you’re an experienced facilitator, you can just skip those info boxes. It’s 24 antipatterns, which are aimed at how do you plan a retrospective? What about the people in the retrospective? How do you structure it? And then for each retrospective antipattern there is a little section about if it’s an online retrospective, then what are the differences in the refactored solution? What should you do differently? Like the thing I said before with the round robin is good if you’re online and putting people together two-and-two is easy if you’re not online.

I expect that people will read at least the introduction where they get introduced to the concepts and get an overview of all the antipatterns. And then I’m guessing that they would probably skim the antipatterns and then they can go back to them. So antipattern is about awareness. It’s about putting a name to a situation that you can end in. It’s about being aware, “Uh oh, I’m in a wheel of fortune right now.” Or, “Oh, I shouldn’t do a prime directive ignorance.” Or something like that. If you feel that you’re there, you can remind yourself what was the refactored solution. So in each antipattern, there’s the context, this is the situation you’re in. And I use, I have a little story from a Danish company, which is made up. So every antipattern starts with that story. What’s the situation for this team. And then there’s a general context, which sort of broadens it out, abstract it a bit. And then there’s the antipattern solution. This is what people normally do in this situation because they don’t have enough time. They don’t have enough experience. They’re afraid of things. And then these are the consequences of doing this antipattern solution. And then this is a refactored solution. And then I have a personal anecdote in the end. And the personal anecdotes are actual anecdotes from my facilitation experience. I don’t mention any company names. I don’t mention any names. I have changed the gender of some of the more annoying people in my anecdote, so they should not be recognizable. But I’m sure that in one or two cases, some people will recognize themselves.

Henry Suryawirawan: [00:54:29] Interesting. So you mentioned some of these antipattern names. For those people who haven’t read it, maybe you can name what are the most top common antipatterns where people can maybe just go through and see what those mean.

Aino Corry: [00:54:41] The prime directive ignorance is where you are afraid of using the prime directive with the team, because you think they might think it’s ridiculous or too hippie-ish or not something that they can believe in. And then you decide to ignore the prime directive, and then you might end up in a naming or blaming game with the team.

And then also wheel of fortune, I’d like to mention, because there’s a lot of people who use those retrospectives—Where the activity is? What should we start doing? What should we stop doing? What should we continue doing?—that’s how they gather data. But then they go directly from data gathering to the conclusion to deciding what to do. So for instance, if they say, “We should do more pair programming.” That go directly to, “Okay. Let’s schedule a three hours of pair programming three days a week for 80% of the people in the team.” That’s a very good solution, if the actual problem is that they forget to do pair programming. But if the fact that they don’t do pair programming is just a symptom that they don’t have psychological safety or trust. They’re afraid of letting other people look at their code or they don’t have the technological support to do pair programming, or they don’t know how to do it to gain the benefits. Then scheduling pair programming won’t help because it’s just working on the symptom and none of the actual problem. So that’s wheel of fortune. I see that all the time.

Henry Suryawirawan: [00:55:53] Thanks for sharing that. For those listeners who are interested in these two—prime directive ignorance and wheel of fortune, I would suggest go to the book, find it, and read it. What those antipatterns mean? And how you can actually refractored to come up with a refactoring solution to the problem.

Personal Retrospective [00:56:07]

Henry Suryawirawan: [00:55:53] So we are moving towards the new year 2021. And I know many people like to write resolutions or maybe looking back (at) retrospectives. I know 2020 has been a tough, challenging year for many of us. So is there any tips how a person, an individual can do retrospective for themselves?

Aino Corry: [00:56:26] I think that the important part of that is to acknowledge that it is a good idea to have a retrospective with yourself and to set aside time for doing it. I don’t care if you’re using a document or if you’re using post-it notes or whatever you’re doing, but try to go through the five stages. Really remind yourself in the beginning, why are you doing this? What do you expect to get out of it? Gather data, maybe looking at your calendar, looking at your emails, whatever you need. Looking at your Git commits or whatever. And then try to, again, don’t come up with seven things that you need to do. Don’t come out with I need to write a book and do yoga every day and lose 10 pounds and start learning functional programming and write about nomads in a blog post. Don’t set yourself up for failure. Try to have like one, two, or three new things that you want to try, and call it experiments because an experiment is a success even if it fails. And I think calling something an experiment instead of an action point can relieve some of the stress around it.

I celebrated new year, many years with a Quaker group. I’m not religious myself. But every new year’s eve, we’d sit in silence for an hour between 11 and 12. And the only thing that you could do sitting in that silence was actually reflecting on the last year. And that was wonderful. So just setting aside an hour of complete silence, just keeping that in your brain. And then at 12 o’clock, you’ll hear all the fireworks and the bells outside. So you’ll know when to stop or you can set an alarm. I found that very good.

3 Tech Lead Wisdom [00:57:51]

Henry Suryawirawan: [00:57:51] Thanks. So Aino, we’re coming to the end, but as a normal question that I have for every guest that I have is for you to share three technical leadership wisdom that you want to share with the people, the listeners here, for them to think about, or maybe if they can relate to it, they can implement those as well.

Aino Corry: [00:58:08] Yeah, of course. I’ve gone a bit meta. The one thing is, don’t ignore the prime directive with yourself. Remember that you did the self you could with the resources you had at hand, the things that you knew at the time. So don’t be so hard on yourself. When you screw up or you make a failure, you remember the prime directive, I’m sure you did the best you could with the energy you had also.

The next thing is to retrospect with yourself, as we talked about before. Have a retrospective with yourself at least once a year, but it could also be, as I said in the beginning, it doesn’t have to be a whole hour with post-it notes if you are just you, it can also be just lying in bed at night and thinking about what happened and what can I learn from this situation?

And the third one is keep learning. Some people sometimes ask me, should I change job? Or should I stay where I am? And I asked them, do you still learn something? And if they say no, then I say, well, maybe you should change then, because I think that if you keep learning, it’s a good sign that you are being challenged and you’re developing yourself and you have time to reflect because otherwise you can’t learn. If you’re not learning, it can be a symptom of a lot of different things that you’re stuck in a trap, that you’re doing the same things over and over again and it’s taking the energy out of you. That you don’t have time to learn anything because you just pulled through a lot of things and you’re only doing a mediocre job because you don’t have time to actually improve your skills or improve your knowledge. So keep learning, make retrospectives with yourself, and remember the prime directive holds for you as well. You did the best you could.

Henry Suryawirawan: [00:59:36] I like that. I mean, for individual, sometimes we kind of like blame ourselves as well, especially if we make mistakes or we chose the wrong thing. I think it’s really important that you share this —don’t ignore prime directive, even if it’s just for yourself. Because we should have like compassion for ourselves as well. Don’t blame yourself just to do the wrong thing in life.

It’s been a great pleasure talking to you. I know I really enjoy this, learning so much about retrospectives. I must say that as individuals, sometimes I find it hit and miss. So there are some retros that I really enjoy going to. There are some which are not so enjoyable. But looking at all these discussions that we have, I think there are a lot of things that everyone can try to implement, or even just by reading your books and understanding what are the antipatterns that people can be aware of. And having the name, I think that’s also very important so that we can all improve our next retrospectives. Thanks again, Aino. So for people who are looking forward to connect with you, or maybe look for your books, can you maybe share where can they find you?

Aino Corry: [01:00:31] Well, I have a website called Metadeveloper.com. And there’s one of the tabs called “New Book”, and you can find the antipattern prime directive ignorance there for free that you can read. Well, I’m on Twitter and I’m on LinkedIn. If you want to connect with me on LinkedIn, it’s a much higher likelihood that I’ll accept if you write why you’re linking in with me. So I don’t feel that it’s just somebody trolling through the network and getting as many links as possible.

Henry Suryawirawan: [01:00:55] Okay. Thanks again, Aino. Hope for the best for your new year 2021 business and consulting.

Aino Corry: [01:01:01] Thank you very much, Henry. Likewise. And thank you for having me today.

– End –