Reflecting for Success: The power of team retrospectives

About this podcast episode

🎙️ Reflect, improve, repeat, and enjoy the benefits of improved team collaboration

We are thrilled to have Aino Vonge Corry as a guest to share how retrospectives can foster team collaboration.

Aino and Bill Raymond share stories and reflect on their careers to share how agile retrospectives provide a platform for teams to reflect on their work, learn from their experiences, and continuously improve their processes.

In this podcast, you will learn the following:

✅ The definition of a retrospective

✅ How to avoid negativity

✅ Who should run retrospectives

✅ What to expect as a result of a retrospective

🎉 The core tenets of running a successful retrospective

Transcript

(transcripts are auto-generated, so please excuse the brevity)

[00:00:00] Guest clip

[00:00:00] Bill Raymond: What happens when you get into a situation where you’re in a retrospective and the same issue just keeps on coming up and it doesn’t feel like you’re making any progress on it?

[00:00:08] Aino Vonge Corry: There could be a lot of reasons for this happening. One reason could be that, you are discussing symptoms instead of the real problem.

Another reason can be that you’re discussing something that’s actually out of the influence of the team.So one of the anti patterns in my book is called In the Soup, So the refactored solution is to use an activity called the soup diagram, where you draw three circles, a small one in the middle, where these are the things that you can do something about a bigger one outside, which is the things that you can influence.And then outside the two circles, you have the soup. And the soup is just the reality that you live in, you can’t change the things in the soup.

[00:00:48] Speaker: Welcome to the Agile in Action Podcast with Bill Raymond. Bill will explore how business disruptors are adopting agile techniques to gain a competitive advantage in this fast-paced technology driven market.

[00:01:08] Podcast

[00:01:08] Bill Raymond: Hi, and welcome to the podcast.

[00:01:09] Aino Vonge Corry: Today I’m joined by Aino Corry PhD, author of Retrospective Antipatterns, and founder of Meta Developer. Hi Aino. How are you today? Hi, bill. I’m great. Thank you. I hope you’re well as well.

[00:01:21] Bill Raymond: Yes, I am. Thank you very much. Today we’re going to talk about reflecting for success, the power of team retrospectives. I’m excited for this conversation because throughout the last few podcasts, especially through Fall and winter 2022 and 2023. We talked a lot about Scrum and we talked about the importance of various meetings such as sprints and retrospectives, but we never actually did a deep dive into retrospectives, so I’m really excited to do that with you today.

[00:01:52] Aino Vonge Corry: But before we get started, could you introduce yourself? I could. Yeah. As you said, my name is Aino Corry, I am Danish. I live in Denmark. I’m 52 years old, I think. Yeah. And after my PhD I went back and forth between research and industry for about 10 years teaching in academia and teaching in industry and being a software architect and a developer at times.

And then I decided to start my own company. So I’ve been an independent consultant, mostly an agile coach for the past, I think 15 years, something like that.

[00:02:25] Bill Raymond: By the way, you have the best website ever. I love this. You have a sort of a sticky pad montage on your website that I absolutely love.

[00:02:34] Aino Vonge Corry: it was actually my, my, one of my younger brothers who’s a photographer that that proposed that we should do it like that, that I was immense in the posted note wall. I thought it was a great idea.

[00:02:44] Bill Raymond: It. It is a great idea. It really stands out. So before we get started we are going to, Do a deep dive into retrospectives, but maybe you could just kick this off with a quick overview of what a retrospective is.

[00:02:57] Aino Vonge Corry: Yeah, I can. So a retrospective is a recurring meeting in the team where they set aside time to reflect together. So that they can learn what happened, appreciate what happened, and adapt their behavior to the situation. To me, retrospective is the core of agility, the core of being agile, to inspect and adapt and to be able to inspect.

You need to actually learn. It. It’s a session where everybody in the team sits together and tries to understand and makes meaning of what happened and try to learn together so that they can improve the way that they work. Sometimes people have retrospectives. About the sprint that just happened, about maybe why didn’t we finish all the tasks?

That could be a theme, or it could be did we bring the value that we thought we would bring? Are we going to reflect a little bit about what we believe value means? Or it could be something specific like the testing process, or new things you’re trying out.

You mentioned a lot about teamwork and that being one of the core elements of the retrospective. A lot of times when you’re having a retrospective, it’s, as you said, it’s after a sprint and you’re looking back just a few weeks.

[00:04:08] Bill Raymond: But is that the time to also talk about how you’re going to work on the product and plan out the next two weeks?

[00:04:15] Aino Vonge Corry: No, it isn’t really I think it’s quite important that the retrospective time is really focused on understanding together, sharing and learning together, and deciding what to do of things that will change the way that we work together.

The discussions about the product and the functionality should be placed somewhere else, and I think it is actually quite important for a retrospective facilitator, the one that is leading the.

The retrospective that the facilitator keeps it focused on these things so that we don’t just start talking about what happened in the weekend, or we don’t go into a very detailed technical discussion about some sort of functionality that needs to be changed somewhere in the system. It’s important that the retrospective is a meeting for the whole team where it’s not just two people talking or people talking about the weekend or the holiday.

[00:05:04] Bill Raymond: Yeah. I actually know someone that, was telling me about the fact that they were leading retrospective meetings and how well they were going and how they had adopted them and he really liked the way it was going, and then received some negative feedback when it was time to do some team reviews.

And it turned out that the reason for why. He was excited was because everything was talking about the technical side of things. What, what is this cool thing that we can do with the technology? What are some ways that we can advance this, which are all great conversations and everyone was highly engaged in it.

But folks did not feel that the meeting was being run properly because they weren’t figuring out how to work better as a team. They kept going right back to the technology piece. That was a really big learning for him. And he and I know that he took that to heart and, and started working on it.

But I, I do think that’s an easy fallback position, right? You’re sitting in a team with a team of people and you just got this. Cool work done, and what is one of the things you wanna do? You want to talk about that work and how you’re going to progress it, but really you do need to do a little bit of a shift in your mindset, don’t you?

[00:06:19] Aino Vonge Corry: Definitely yes, and I think it is very easy to have a retrospective that. That’s is I wouldn’t say wasted, but that’s spent on other things, like discussions about technical details or new functionalities or I in the architecture, especially if the facilitators also technical him or herself.

And that’s actually one of the, one of the problems with the being. I know you didn’t ask me this question, but there’s a lot of people and teams where it is always the scrum master that is facilitating the retrospective. So often the scrum master is part of the team as well, so they’re both a developer and a scrum master.

And then because they’re the scrum master, they facilitate all the retrospectives. But the problem here, I think, in the long run is that if you are always facilitating the retrospectives for your team, then you don’t really get. A retrospective yourself. And the other thing that can happen is that you start discussing things that you think are interesting in the system instead of actually facilitating a retrospective.

Because when you are facilitating retrospective, you put on a certain hat and you are focused on the agenda, the plan that you dreamed of before the retrospective. You are focused on the body language, you’re focused on the time. You’re focused on the energy in the room. Are we actually. Are we finalizing these discussions?

Are we, when do we move to the next subject? What should we do? Should we have experiments or action points at the end of the retrospective? And when you are facilitating, you are focused on all these things. So you can’t be part of the retrospective. You can’t be part of the discussions because if you start to become part of the discussions, then you put on another hat and you don’t notice that other people may have stopped talking or the energy in the room is going down.

Or maybe you forget to keep an eye on the time and suddenly the time is up and you haven’t reached any conclusions in the retrospective. So I think that often happens, that situation that you talked about when it is somebody who is also part of the team who is facilitating and somebody who’s also technical because that’s what they’re interested in.

So what I. What I propose for people is that instead of having the same person facilitating all the times, you could actually shift it around in the team. Maybe there are some other people in the team who would like to try it out. And if they’re not very experienced in facilitating retrospectives, there are some great online tools like neatro.io or Retrium that will take you by the hand and lead you through the retrospective as a facilitator.

And if you’re doing it in real life, there’s a lot of board games you can download from the internet that will make you play the retrospective as a board game. And also if you have somebody else from the team facilitating a retrospective. They will see that it’s actually not that easy to facilitate a retrospective.

It seems simple, but it’s not easy. It’s like losing weight. That’s simple, but it’s not easy. So try to avoid having the same person facilitating all the time because you’re running some problems, particularly the one that you just mentioned.

Yeah, that’s a really good idea. I like that. And there are times when maybe things can even get heated and it might be time to bring in a coach or some facilitator. Yeah. Yeah. I have seen some organizations, big organizations where they have several teams and they have maybe a handful or 10 people in the organization that likes to facilitate retrospectives, and then they set up sort of a, a schedule for. The fact that they can facilitate each other’s retrospective so that they can, from time to time just be part of their team and have somebody else facilitate the retrospective so that they can get something out of it as well.

[00:09:52] Bill Raymond: That’s a great idea. I like that a lot actually. What should be the outcome of a retrospective?

[00:09:56] Aino Vonge Corry: The outcome of a retrospective should be that you have shared an understanding so that you know how other people have experienced either this sprint or this project or this incident. And then the second thing is that you appreciate what happened to other people instead of saying, ah, you were an idiot, or, ah, haha, I, it’s ridiculous that happened and good on you, but that you actually appreciate that things.

Some things were good and some things were bad. And then the third thing is that you learn something and you take actions with you, and it’s quite important that you actually leave the retrospective with some tangible things. Perhaps one or two action points, perhaps an experiment that you want to try and that you actually follow up on the things that you take away with you from the retrospective.

Because if you spent time on reflecting together, coming up with ideas for what to do and then don’t implement it, then the time is really wasted. You are still sharing and appreciating, but you don’t really get that learning out of it.

[00:10:58] Bill Raymond: Can you just share maybe a few examples as to what might come out of a retrospective?

[00:11:03] Aino Vonge Corry: Yes. There are big things and there are small things, and one of the things that I experienced recently was in a company where I was facilitating a retrospective for the leaders in the company. So I don’t just facilitate retrospectives for developers and engineers, but also for the leaders, for data analysts, for all sorts of people, because I think it’s important that everybody gets a chance to reflect.

So I was facilitating this retrospective for the leaders, and they had the problem that when they had meetings together, the one who invited for the meetings had written in the calendar invitation, what she wanted them to prepare for the meeting. Like what she wanted them to ask the team about or what kind of statistics she wanted them to bring or data.

And then she expected when she turned up that the meeting, that they’d done it and they didn’t read the calendar invitation until right before the meeting. And then when they showed up, they hadn’t prepared anything. That had been going on for a few months and she had assumed that once they understood what she wanted, they would change their behavior so that they would read this in a good time before the meeting so that they could prepare.

And they, on the other hand had assumed that she must now understand how they work, so that she probably doesn’t put anything important into that calendar invitation because she knows we’re not reading it. So they had soured on each other more and more, and it started to come out as irritations about the meeting.

But once we started discussing it in the retrospective and we made some cause analysis, we actually found out that this was the problem. This was the original problem that they had these different assumptions and every meeting started on the wrong foot.

So I think that, yeah, so So what they decided to do was, That if she wanted them to prepare something, she would send a separate email so that they would so that they would prepare.

And that’s something that they would read because apparently they’re not reading the calendar invitations. There was also somebody who who proposed, of course, that she could invite them for a fake meeting uh, where they had time to prepare this. But that was not that was not chosen as the experiment that they should try.

And it’s interesting how they started it, started over here discussing the very bad leadership meetings. But then when we dug into it, it turned out that actually a lot of the aggravations were because they started with the wrong assumption. So that’s one thing. One result of a retrospective, which is a tiny thing really, but that has made them be a lot more happy.

There are like other things that can happen is that you might say we don’t have enough pair programming. I like pair programming. We should have a lot more pair programming. And then other people are saying yeah we’ve seen Dave Farley’s uh, podcast about pair programming. We read Martin Foyler’s about pair programming.

Of course we’ll do that. We are convinced it’s a good idea. And then the immediate action might be to say let’s schedule some pair programming in our week. But if you have a retrospective, a real retrospective, what you do is that you try to generate insights. You don’t just take the problems that pop up for granted.

So you instead of saying, okay, this is apparently the problem, we don’t have enough pair programming, you’re actually digging into it in the generating insights part of the retrospective and trying to figure out why don’t we have the pair programming because if it’s just because we forget it, it’s a very good solution to schedule it more.

But if the real problem is, or the real cause is that there’s not enough psychological safety, people don’t trust each other to look at them while they’re working, then scheduling more pair programming will actually make the problem bigger probably.

[00:14:44] Bill Raymond: Yeah that’s a really good point. So I guess I, This could be a much larger conversation than we have time for the podcast. But you mentioned a few things there. Some of this is just about setting expectations. Some of it’s about taking actions on things that areif you will, a bit more of an immediate, we can, we can leave this room and start working on them, actions that come out of it.

But then there can also be the human resources side of it where maybe there are people that don’t get along and I do wonder sometimes, cuz I have seen this of course, where people start getting into it in a meeting about the, that person over, there’s working style or, I’m always waiting for that person.

And that can turn into a situation where, the team is almost going at each other as opposed to coming up with results. And I think sometimes a good facilitatorcan help with that, but other times it, it speaks to a bigger problem is this isn’t the place for speaking to those larger problems, is it?

[00:15:45] Aino Vonge Corry: No it isn’t because you have only a limited time set aside, and it is only the things that the people in the room can do something about that you want to change and it is important to try to focus on discussing things that the team can actually do something about and changing somebody’s behavior might not be something that the team can do something about.

They might be able to change the framework around that person or the process around the communication with the person. And that might enable the person to act a little bit more like they, they hope that they will act. There is often this complaint about retrospectives that I hear is that we don’t want to have a session where we are naming something, naming somebody, or blaming somebody in the retrospective.

But what do you do if the problem is that we do have an idiot in the team or somebody who is really lazy, that I often hear that what if somebody really needs to get fired? And I said it’s as you mentioned, Bill, it’s not the responsibility of the team to fire somebody, but if there is a recurring problem, then they might be able to say to hr, to management, and the only thing that you can do in the retrospective is to go in there with an open mind using the brand directive from Norm Curth and saying, I believe that everybody did the best they could, given what they knew at the time, the resources at hand, and how tired they were that day.

If you’re going into the retrospective with that mindset, then you are trying to find faults in the system and not faults in the people. And I think even though you might think that you have a colleague who’s really not doing the right things, you could start thinking about it in that way and thinking, is it a skillset that they need?

Do they need more time? Do I need them? Do they need the right data? Do they actually know what’s expected from them? Can they even do it? Because otherwise it doesn’t really help. And this leads me to another interesting thing about retrospectives. they cannot solve all the problems and retrospectives in themselves solve very little of the problems.

But what they can do is that they can shine a light on the problems that you have. So that you can see that you have problems, and then between the retrospectives you can work with these issues, but it’s a way of lifting the carpet to see what’s hiding underneath that carpet of ugly, nasty things that we need to take away.

So I think it’s okay to have high expectations to how much you can understand in a retrospective, but you shouldn’t have too high expectations about how much you can change in the retrospective. It just feeds you with inspiration of what to do in between.

[00:18:18] Bill Raymond: Now, you wrote a book called Retrospective Anitpatterns, so can you me, can you explain what you mean by antipatterns?

[00:18:26] Aino Vonge Corry: A pattern is an abstract solution to an often recurring problem, right? And a pattern is a solution that you can implement in your own way a million times without implementing it the same way. So patterns is something that you see in code, in design, in architecture, in behavior that shows experience.

It shows good solutions to often recurring problems. Now, antipatterns is almost the same as a pattern, but an antipattern is a bad solution that you see over and over again. So you recognize it as a pattern and then you call it an anti pattern because it’s something that you do that you think is the right solution.

But because of the context or the time or place, it isn’t actually the right solution for this. And then in an antipattern description, there’s also a refactored solution that gives you the solution to the problem that is created by the antipattern. But it’s interesting this um, relation between patterns and antipatterns because some people say that patterns are great and anti-patterns are really negative and bad.

I don’t see anti patterns as negative and bad. I see them as a, an as an awareness. When I’m driving my car and I see a stop sign that’s not necessarily negative, that makes me aware that there is a potential danger here. That’s why I have to stop. And as an example of the relation between patterns and anti patterns.

Most people have probably heard about the microservices architecture pattern that has been spread I don’t know, 10 years ago. And then everybody had to have microservices. Everybody had to drill down their monoliths and be and create microservices because that was the right thing to do. But now we know that not all organizations actually have the support and the people and the culture that enables microservices to be a good solution. In those situations, when they create microservices out of their system, what they get is just a more confused monolith, a more difficult to maintain monolith. In some situations, the microservices pattern is a pattern, and in other situations it’s an anti-pain.

Although it is the same solution, you can see that in some places it’s positive. Some places it’s negative. And as an example of an anti pattern in in my book, retrospectives Anti Patterns is the loud mouth. Just to find a simple one. So the loud mouth is an anti pattern where you are in the situation where you’re facilitating retrospective and you have somebody who’s talking all the time like me right now.

And nobody else is allowed to say anything. They interrupt people or they give long speeches and they just talk all the time. And as a, perhaps a novice facilitator will think in the retrospective, people should be allowed to talk about what they want so they’re not interrupting the loud mouth.

They allow the loud mouth to, to say what they’ve got, what they need to get rid of. And it’s a pattern that I often see in retrospective facilitation that they allow the loud mouths to be loud mouths, and it’s good to some extent. But you have to remember that with the retrospective, you might have 90 minutes for nine people and you also need time in silence to write things on post-it notes and for the facilitator to summarize or to explain an activity.

So if somebody talks for 15 minutes, it’s just not good enough because the other people won’t get enough time to share what they think about. So the antipattern solution is that you just allow the loud mouth to speak, but the refactored solution is to say, okay, I’ve realized I have a loud mouth.

I will change the way that I facilitate this retrospective. Instead of having plenary discussions, they should be writing more down, or perhaps I’ll make breakout rooms so they discuss two and two so that the loud mouth will only contaminate one other person and not everybody in the retrospective.

[00:22:17] Bill Raymond: Yeah. And I think there’s a few different elements to that. I know that there’s times when you’re in a meeting and you have the loudmouth, but the loudmouth is often looked at as someone that’s very respected and has a lot of good ideas, and they’re able to just get out whatever they need to, need to get out.

But there is a expectation that everyone has a say in the conversation and other people might have other things that they need to bring up, and that those kinds of anti-patterns can break down a team over time.

[00:22:49] Aino Vonge Corry: Completely. Completely. And the reason why we have retrospectives, as we talked about in the beginning, was to have a meeting with the whole team. If we wanted the presentation from the loud mouth, that’s what we would’ve asked for, but, it’s interesting also what you say that often the loud mouth is high in the hierarchy or a respected person that’s used to getting time to speak because that’s also something, that’s it.

It’s a self-fulfilling prophecy because often the loud mouths are the people who are active thinkers and with active thinkers. Somebody who needs to talk to think. There are some people that you can actually, if you listen to what they’re saying, you know, that they can’t think without saying something.

That’s why they’re talking. To think. And then on the other end of that spectrum, there’s a, the reflective thinkers who need to reflect before they say something because they need to think in quiet before they say what they’ve thought about. And it’s interesting because the people who are active thinkers who can immediately answer all the questions, who can immediately talk about the relations between things in the system who just speak out, they are often interpreted as being more intelligent than the reflective thinkers, even though that might not be true at all.

So the loud mouth. Because they’re answering questions quickly and they’re talking about what, how things are related. They might be perceived as being more intelligent, and while they’re perceived to be more intelligent, they’ll get more speaking time because they’re more intelligent. And then we completely forget to listen to the silent thinkers or the reflective thinkers who actually have spent time thinking and reflecting.

And it would be great to have their understanding on the table as well. But as long as the loud mouth is talking, they don’t get to think

[00:24:30] Bill Raymond: What happens when you get into a situation where the, you’re in a retrospective and the same issue just keeps on coming up and it doesn’t feel like. You’re making any progress on it?

[00:24:40] Aino Vonge Corry: This happens a lot, I think, and there are a lot of, there could be a lot of reasons for this happening. One reason could be that, You are discussing symptoms instead of the real problem, as we talked about with the pair programming. So if we are only working with the symptoms and not spending the time to find the real problems, then even though you are like solving the symptoms again and again, the problem is still there.

It’s it will still pop up either in this form or in a different form. So that could be one reason for discussing the same over and over again. Another reason for discussing the same thing over and over again can be that you’re discussing something that’s actually out of the influence of the team, that they can’t do anything about it.

So one of the anti patterns in my book is called In the Soup, and this is an anti pattern that you are in if you consistently discuss some things that you cannot change and in the soup, then um, Also alerts to the refactored solution. So the refactored solution is to use an activity that I learned from Diana Lassen called the soup diagram, where you draw three circles, a small one in the middle, where you say, these are the things that you can do something about a bigger one outside, which is the things that you can influence you can say something about you can escalate.

And then outside the two circles, you have the soup. And the soup is just the reality that you live in, you can’t change the things in the soup.

And as an example, I had a, another team that they had been irritated about a vendor system that they had to use and it had been frustrating for them in the past six months.

And

Okay, I said, what have you tried? We’ve tried everything. We can’t change it. So the discussion was going in a circle and I said if you tried everything and you can’t change the situation, this is definitely in the soup.

And that means it’s something that you just have to accept and you have to learn to live with it. Sometimes I introduce a Gnome that I’ve introduced in my own home that In order to accept the situation, you might sometimes make it a bit ridiculous or silly. For instance, in my life I have my husband, he, when he takes a shower in the morning, he puts up his towel on the hook so that it can dry for the next day.

But then unfortunately, we have a little gnome. That sneaks into the bathroom every morning and takes his towel and crumples it up as a big wet thing that lies on the floor. He had put it up on the hook like he should, but then the gnome is throwing it on the floor. And when I come out in the bathroom, I’m like, ah, that gnome was here again.

And my husband is saying, really, I don’t understand. Let me put the towel up. I don’t understand why the gnome always does that. And what what happened there was that when we introduced the Nome, instead of having something which would frustrate me every day, we created something that I laugh about every day.

And I think that mindset thing, like the prime directive mindset that you. You try to take on the mindset that everybody did the best they could instead of trying to find faults in people. And if there is something that they just cannot change, that irritates you. Or if there’s something with a vendor system that you cannot change that irritates you, try to make it silly, try to implement a gnome or try to say that Whenever we, we realize this we whistle a certain song or something like that.

Just something that makes you think about it in a different way because just complaining about something that you cannot change makes you miserable, and it also makes you miserable to be around.

[00:28:09] Bill Raymond: Yeah, and then it just ends up being that one thing that everyone just talks about all the time, and it’s this shared frustration that makes you feel like you’re not getting going to get anywhere else because of this one giant, thing that’s a problem.

I have seen in a, in a number of instances where I’ve been in retrospective and these big ticket items come up where they can’t address it. And, what we do is we hold a retrospective, invite some of the leaders in, because maybe the scrum master or the product owner or the, someone you know or, or a manager, Tried to take on the issue and didn’t quite get anywhere.

But when you sit down if you’re, if you are a leader and you’re sitting down with the people that are working on something important to you, and it’s on your budget and you’re finding out that people can’t be as productive I think you, I think it’s fair to bring them into a retrospective occasionally when you need them to help you with an issue so they can see the challenges in front of them.

[00:29:12] Aino Vonge Corry: I think that’s a very good point, bill and I actually, the soup diagram that I talked about before, I sometimes use that to, to talk to the team about inviting maybe a manager or somebody from a different team, because if we have something that’s in the soup, something that’s out of our sphere of influence, then her definition, if we invite some more people, our sphere of influence will become bigger. So if we invite the people who can actually change this, maybe another team or a manager or somebody like that, then we can have a discussion where we can actually discuss something that people in the room can do something about.

But then when you do invite a manager to the retrospective you should make sure that the team is okay with it. Because there might be some managers that make people shut up or not talk about the negative things. And also it’s my experience that there are some managers who are saying, oh, I’ll just be a fly on the wall.

I’ll just be sitting here listening in. I won’t be barging in or anything like that, and that’s actually worse. I say if they’re in the retrospective, they should be part of the retrospective. Then they should also answer the question in the beginning. They should also write post-it notes. They should also vote for what we should do.

They should be active participants if they are there.

[00:30:25] Bill Raymond: Yeah. Yeah, cuz then at that point you’re just either, you’re micromanaging or just being nosy.

[00:30:31] Aino Vonge Corry: Yes exactly. And none of those are not, none of those are good.

[00:30:34] Bill Raymond: Yeah, exactly. And then you think you have this person that’s listening and they’re not, because they’re actually responding to some Slack message or something and that’s not being engaged either.

[00:30:44] Aino Vonge Corry: That’s also very typical, especially if people are there without camera unmuted. You just like it might be a symptom of a problem that you should deal with, right?

[00:30:53] Bill Raymond: Yep. Yep. So we only have a few minutes left. What are the key tenets for running retrospectives?

[00:31:01] Aino Vonge Corry: It’s quite important that you remember when you run a retrospective that you are dealing with people and not machines. So a normal human brain needs time to take in information, process it, and work with the information and communicate it. So you can’t optimize a retrospective. You should actually remember to spend the time that it takes for a brain to learn and process things. I have, I’ve heard some people saying that they have optimized the retrospectives so that it only takes 15 minutes. They just ask everybody around the table, how is everything? And then they say yes, and then they leave, and then they’ve done the retrospective and they’ve done it very efficiently and they brag about it to me, and I say that’s that’s not a good thing to do if you really want to share and appreciate and learn together, you need to spend the time about it. So I would say that two or three weeks in between the retrospectives take about 75 to 90 minutes with the retrospective. Otherwise you won’t really get the best out of it.

[00:32:02] Bill Raymond: That one in particular was interesting to me because we do see that, right? We do a thing called a sprint meeting at the beginning of a day. At the end of a day. Some organizations have adopted it, some haven’t. It’s this concept of, at a regular checkpoint within a sprint that you’re doing your work.

Usually one to two weeks you’re meeting with folks and for 15 minutes, and you’re asking questions along the lines of, what did you accomplish? What are you gonna accomplish today and are there any blockers? And we just wanna celebrate some wins and also make sure that there’s nothing that we need to worry about that is not what the retrospective is.

[00:32:40] Aino Vonge Corry: No, it’s not, no, it’s not a short focused meeting. It’s a bigger structured meeting. And there are some teams that say that they don’t need retrospectives because they’re so good already, and that’s simply not true. There’s always something you can optimize. To me, retrospectives is like going to the dentist, getting your car checked, or training for a marathon.

You, you might be able to run a marathon without having trained for the marathon, but not without getting any injuries, and it won’t feel very good the next day. So the more that you can fix the things along the way, the better. So even teams that think they’re good can become even better. As an example, when I started introducing retrospectives in my family, I’ve got a husband and three children. I was under the impression that we were talking well, as a family, I mean, we sit down for a dinner every evening, we talk about what the day has been like.

But then I introduced the retrospective at the end of the year with the family, and I know that was after a year, but there was some magic that happened. We suddenly, we sat down and rere reflected together and we reminded each other about things that we could maybe have done in a different way as a family.

We reminded each other about things that were actually pretty nice and we should do that again, and we shared. We shared our experiences. So my husband and I had one experience about a camping trip and it turned out that the kids’ experience were quite different, right? We never wanted to do it again.

They thought it was the best thing that ever happened. And even though we knew that, we didn’t know to what extent it was that important for the children. So I think the analogy here is that even though you think you are a great team and that you talk together about the problems, setting time aside to really reflect and share can sometimes be very surprising.

It can be a great experience and you can actually learn something from it.

[00:34:28] Bill Raymond: I really appreciate everything that you shared today. Aino Corry, how can people reach you if they wanna talk about this further?

[00:34:36] Aino Vonge Corry: You can find me on LinkedIn. I think Bill will share the link to my LinkedIn in the notes. And if you just write I heard you talk on Bill’s podcast, then then I’ll connect to you and then we can have a conversation if you want it.

[00:34:48] Bill Raymond: That’s wonderful. Thank you. I’ll make sure that your LinkedIn link is on the agileinaction.com podcast. And if you’re in a podcast app right now, you can just go down to the show notes, the description, and you’ll see that there. I’ll also link to your website.

I’ll link to your book, which is retrospective anti patterns, and I definitely suggest that you at least go to the website just to see the photo.

[00:35:10] Aino Vonge Corry: Yeah. And the cute pictures of the octopus.

Oh, that, that’s, yeah, that’s on the side about the book.

[00:35:16] Bill Raymond: Thank you so much for your time today Aino Corry. I really appreciated it.

[00:35:20] Aino Vonge Corry: Thank you very much, and thank you for inviting me, Bill.

[00:35:22] Outro

[00:35:22] Bill Raymond: Thank you for listening to the Agile and Action Podcast with Bill Raymond. Subscribe now to stay current on the latest trends in team, organization, and agile techniques. Please take a moment to rate and comment to help us grow our community. This podcast is produced in affiliation with Cambermast LLC, and our executive producer is Reama Dagasan.

[00:35:44] Speaker: If there is a topic you would like Bill to cover, contact him directly at bill.Raymond@agileinaction.com.​