Aino Corry on Retrospective Antipatterns

Shane Hastie: Hey folks, with QCon Plus fast approaching we've just announced our full schedule and speakers. Join world-class domain experts, Katharina Probst, senior engineering leader, Kubernetes and SAS at Google, Sergei Fedorov, director of engineering at Netflix, Matthew Clark, head of architecture of the BBC's digital products and many more this May 17 to 28. You can expect deep technical talks from software leaders, driving innovation and change. Our focus on patterns and practices and real time interactive sessions. Join over 1800 senior software engineers and learn what should be on your radar. Visit qcon.plus for more information.

Introductions [01:04]

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ engineering culture podcast. I'm sitting down across the miles with Aino Corry. Aino, great to see you again. Thanks so much for taking the time to talk to us today.

Aino Corry: Thank you, Shane. It's great to see you again. It's been some years since we worked together.

Shane Hastie: It's been awhile, fond memories of working on a Qcon together. You are the founder of MetaDeveloper, you have a PhD in computer science looking at patterns, and you're the author of the recently released book Retrospective Anti-patterns. So, there's patterns in there. Tell us why patterns.

Aino Corry: Yeah, that's interesting. When I was about to write my master's thesis at the university, I wanted to write about the development of object-oriented programming languages. I was very interested in that at the time, but then my thesis advisor said that you should look at this pattern stuff. It was right after the GOF book release. And he said, well, you should look at this. This is very interesting. Plus, we have an external lecturer coming and then you could help her with her course. Ooh, that's interesting. So, I looked at the book and something just clicked in my brain. That literary form of writing experience down in the pattern. It just resonated so well with the way that I think and the way that I tried to teach, because I was already then a teacher at the university. And I think I've always thought in patterns. For about 18 years, I thought that made me special, but then I looked into the science of brains and how people actually learn, and it turns out everybody learns that way, it's not just me.

The Value of Patterns [02:32]

Aino Corry: It's just a question of knowing that that's how the brain works. That when you get experience with something, you save it in your long-term memory as a pattern, and then you have pattern matching. So, when you see a problem, which matches the pattern that you have in your long-term memory, you have also the solution to that problem in your long-term memory. So, you yank it out and then you apply it. And every time you yank it out and apply it, there's a little bit of a change in the implementation. And that change, you put back into your long-term and, and you refine the pattern.

Aino Corry: In a sense, patterns are essential for learning. Now, when I'm teaching teachers at the university of helps teach computer science now, and one of the things that I'm teaching them is that this is the way the brain works, so if you want to support and facilitate the learning of your students, you should try and describe what you want to tell them in patterns. Give it a name, give it a problem, domain context, explain an abstract solution and the consequences and show them different implementations and let them use it again and again as patterns so that the long-term memory will get it. There was a lot about patterns. I mean, I could talk about patterns all day.

Why Metadeveloper? [03:42]

Aino Corry: Because, when I started my own company, about a decade ago, I was thinking a lot about the name for the company, and I thought I could call it Aino, because my name is so weird, everybody thinks it's a company anyway, when I called. But then, one of my brothers said, why don't you call Metadeveloper? Because you're not a developer anymore. I was way back, but I'm not anymore, but you're developing developers. So I was teaching computer science at the moment. So I was developing developers or facilitating retrospectives and meetings. So I was developing developers. I was inviting speakers for conferences, such as Q con. So I was developing developers. So that's why it's Metadeveloper.

The importance of inspect and adapt [04:28]

Shane Hastie: And what are the development opportunities that developers need today?

Aino Corry: That's a very interesting question. I think the development opportunities that they need today is to understand, for instance, what is actually agile. When I come out, listen to agile coach, I see a lot of different understandings of agile. And to me, agile is very simple. It's inspect and adapt. It's the feedback cycle and the ability to actually react to what you see. And I think that's the thing that's very important for the developers to understand that scrum is a great framework. It's a great process for doing agile and Kanban is, and XP and everything is. But, the point is that feedback cycle and the reaction to the feedback cycle, because its worth nothing if you don't actually react to it. And if you don't have a feedback cycle, which is a cycle and not just say three months, it doesn't work no matter what label you put on it.

Aino Corry: And then, I see a lot of DevOps at the moment as well. A lot of people wanting to start DevOps or dev sec ops, and I think that's valuable as well. But, I think the value to me is the understanding, the respect and the empathy between the two things that used to be silos.

Aino Corry: And of course, the technological support for that is important. But, I think that even the places where I've been, where they have the technological support, I think they're working too little with the empathy and the respect trying to put themselves in other people's shoes and actually understanding. Because I think the ideal solution of developers being able to do ops and ops, being able to develop is great, but along that path, other things need to happen. And I think the humane aspect is important to get there in the beginning.

Shane Hastie: Even today, while agile has been around for 20 plus years, there is a pretty solid understanding of the importance of that collaborative culture and of the people elements, but still today, most developer training is all about the technology.

Aino Corry: Yeah, it is. The short answer is it's sad.

Shane Hastie: How do you fix that?

Asking why rather than addressing the immediate problem [06:25]

Aino Corry: Well, here you go. Shane, I'll give you a quick fix for everybody in the whole world. Well, the way that I tried to do it when I consult with different companies, is I try to understand first why they called for me, because if I just start fixing what they want me to fix, they want me to fix, oh, please make the JIRA set up so that it's easier for the managers to see what the developers are doing, and they're not spending time on the wrong things. Or, please tell the people off for not having full automated testing or something like that. So, I'm asking them always, why is it? And I think that why question that Simon Sineck is on about all the time as well. The why question is important.

Aino Corry: The question is who should you ask that why question to? And I guess that what I do is that I ask it to the sponsor. So the manager or the leader, whoever asked me to come to the company and then the answer is often, and then you had to dive into that and try to figure out, is it just because they heard this on the golf course and they thought it sounded good? Or is it because they looked at the ThoughtWorks radar? And so that agile is a way to do it or that, where did it come from? Does it come from a genuine wish of making the users happier and making the developers happier? Or is it because they want to optimize something and fire some people?

Aino Corry: I think the problem actually lies somewhere else as well. Even though I understand the sentiment of working with the people and the culture, I don't know if that answers it.

Shane Hastie: If only there was an easy way.

Retrospectives to explore challenges [08:08]

Aino Corry: Well, of course, one thing you could do is that you could have a retrospective with people.

Shane Hastie: Why would you?

Aino Corry: Why would I have a retrospective with people? Because what I see when I have a retrospective with people is that they might think that the problem is something, but once we spent time on actually digging into the causes behind the things that they see, sometimes it turns out the things that they see are only symptoms of problems and not problems.

Aino Corry: If we actually spend enough time to generate insights on the things that happened and looking at the causes, the different causes, it's an eye-opening thing. And suddenly they see that something that looked like a technological problem actually is a people problem. That's also something that I hear a lot. And I mentioned that in my book as well, that people question the, oh, so with DevOps, you don't really need retrospectives because DevOps is all about technology and retrospectives is all about the touchy-feely people part.

Aino Corry: And I say, well, I think you will find that DevOps is the main one. So there are people problems there. And you can actually look at the technical things. You can have a retrospective that looks at where the data is, the burndown charts or the testing or feedback or something like that, you can look at the technical stuff. Definitely. But what I see when I look at the technical stuff is that the problems, even in the purely technical stuff, often stems from miscommunication, lack of knowledge at a crucial part in the development cycle or something like that. Fear, fear of management, where they're trying to hide something is often something I see as well.

Shane Hastie: Retrospectives. Great idea. How do you get that openness? The honesty to explore and expose that?

Creating a safe environment [09:58]

Aino Corry: Yeah, that's interesting. Especially for somebody like me, who's an external consultant. How do I walk into a company and make people open in about 15 minutes? It's a challenge. In a sense, it's easier for me because I'm external because they don't see me as a threat to their career. I'm not trying to get their job. I'm not trying to get pay rise higher than this. So, in a sense, it helps a bit to be external, but you have to think about the first 10 minutes of a retrospective are very crucial in order to set up that stage. And I think that one of the things that's important is to try to make people be in the mindset that everybody always did the best they could. And that we're trying to find things in the system that we can improve instead of trying to find faults in people.

Aino Corry: The thing about finding faults in people is something that's deeply rooted in us. Since our parents asked us who started that and who broke that glass and it's even in me, when something happens in my family, I'm asking who didn't put that into the refrigerator after using it or something like that. So it's a very human thing to do, but it's something that we should really try to do when you insert a retrospective system. Norman Kerth wrote something called the prime directive. You should follow that prime directive, when you answer a retrospective or at least you should try, because if you try to have that mindset that everybody did the best they could with the resources and skills and knowledge they had at hand, at the point of time, they didn't mean to do something stupid, they didn't mean to break things, they did the very best they could at the time, maybe they were in the middle of a divorce, maybe they were sick, maybe they didn't have the skills needed, maybe they didn't get the memo, something like that.

Aino Corry: But, if you accept that everybody did the best, then that's a good start of having an open, trustworthy, retrospective. And I think another thing that you should try to do when you start a retrospective is to reduce the tension because when people enter a retrospective, they're sometimes very tense because if something bad happened, they're worried that they will be blamed for that. Or, maybe they're worried what they'll get to know at the retrospective, because in my experience, there's always something new that you hear at the retrospective that they haven't managed to talk about or share between them. So, there's always something new popping up so they can be worried about that. If they're worried about bad news, because they've had it before they can be worried.

Aino Corry: In order to reduce the tension for me, it's very important that we have a round where everybody says something in the beginning because saying something, it reduces tension and itself, unless it's a really difficult question, but I try to make it an easy question. It can be what was the last meal you had? Or it could be, could you described the last sprint as a weather forecast or something like that. Sometimes I ask them, what's the most funny thing you discovered in the last sprint? What's the success you had in the last sprint. It could also be do you play and instrument, or what's the nicest thing a stranger's ever done to you?

Aino Corry: I'm using some icebreaker cards from Equal Experts I found. You can always steal for a retrospective, you don't have to make everything up yourself, just steal, steal, steal people like this stuff to be used.

Aino Corry: If you have a round where people, a. Everybody gets to say something, B. They all get to reflect about something inside themselves and see if you can make it funny in some way, like the, what was the last meal you had, or describe it as a weather forecast, always be something you can have a little laugh at. And that little laugh really does reduce tension.

Aino Corry: Some people ask me, well, how do you make people laugh? We're not always funny, but you don't happen to be funny. That's the thing is that there is tension when you want to laugh. So, you just have to give them the tiniest little excuse. And that could be asking them something weird, maybe in an online retrospective, making something, show something from the background or a toy from the children or whatever, what that purse looks like anything, or say something surprising.

Aino Corry: It doesn't take much to reduce that tension. And once the tension is reduced, then you get smiles on people's faces. And that's where it's very important to have video when it's an online retrospective so that we can see each other. It's very difficult to trust somebody you can't see, but when you have the eyes and the smile, it's easier.

Aino Corry: If people for some technical reason cannot show themselves on video, a picture of themselves helps enormously as well, because then at least you have some eyes to look at and you probably met that person before in a video call or offline.

Exploring the system not blaming people [14:36]

Aino Corry: Once you have that reducing of tension, you can reiterate that what happens in retrospective stays in the retrospectives, and we are trying to find faults in the system, not in individual people. So, I think that's something that's very, and I know that for some people they're thinking, why did we waste seven minutes of our precious time in a retrospective on that stupid thing. But to me, it's crucial to spend time on that.

Anti pattern: Prime Directive ignorance[15:10]

Shane Hastie: You book is called Retrospective Anti-Patterns, what are some of the common things that can go wrong?

Aino Corry: I think I mentioned before, have an anti-pattern called prime directive ignorance. And I have that because that prime directive, there's been a lot of debate online about that prime directive that Norm Kerth wrote, because some people are saying, well, we cannot truly and genuinely believe that everybody did their best all the time, because I know I'm not always doing my best, and I know him sitting over there. He's not always doing his best and she was stupid in the last sprint.

Aino Corry: But, the point is to be brave enough as a facilitator to bring that prime directive instead of ignoring it. So, the anti-pattern is that you ignore the prime directive because you think they will think it's stupid or it's a hippy thing, so you don't say it, and then you start the retrospective and there will be perhaps blaming because of that. So the anti pattern is that you ignore it, therefactored solution that there is free anti-pattern work, the refactored solution is to be brave enough as a facilitator to bring that prime directive.

Aino Corry: It could be in your own words, if they think that Norm Kerth’s words are too hoighty poighty, you can just say, remember, we're trying to find optimizations in the system, not faults. And people just reiterate that every time, in an email, in the invitation or when you start the retrospective. So, that's one of the anti-patterns.

Anti-pattern: Wheel of fortune [16:27]

Aino Corry: Another anti-pattern is the wheel of fortune. The anti-pattern is in order to rush through the retrospective because some people think it's a waste of time. They just do that. Start, stop, continue retrospective, which is not a bad activity in itself. But, the point is what to do after you've asked people, what should we start doing? What should we stop doing? What you would continue doing? If you then just say, well, the things we should start doing, we make them action points now. And the things we should stop doing, and we make it action points that we stop that. If that's what you do, then you run into a wheel of fortune anti-pattern, because sometimes some of the things that you see, as I mentioned before, just symptoms and not the problems themselves.

Aino Corry: So, for instance, if it says we should have less meetings and then the action point is, well, we'll just delete half the meetings. Perhaps the problem was not that you had too many meetings, perhaps the problem was the quality of the meetings. Perhaps you have to have an agenda, you have to have a meeting leader, you have to only invite the people that are really needed, something like that. And then, you could have the equal amount of meetings, but maybe not the same people for all the meetings or something like that. Same with pair programming. A lot of people saying we should have more pair programming, and then that's the action point.

Aino Corry: But, if the problem actually is that they don't want to do pair programming because they're afraid of doing pair programming because they don't trust each other not to laugh at their code, or because they can't work together because one of them is smelly or whatever. You have to look into those causes behind things. Because if you just say, we should have less meetings, we should have more pair programming. Then I'm quite sure that the next time you have a retrospective and you revisit the action plans, they haven't been done because the underlying problem has not been solved.

Aino Corry: So, those were two of the anti-patterns in the book.

Shane Hastie: So how many are there in the book?

Aino Corry: 23, I think. I've been struggling between 23 and 24. So I have different versions in my mind, but it's around that. And it's not because I want it to have the exact same amount as in GOF book of design patterns. It just happened to be like that.

Shane Hastie: It's a pattern.

Aino Corry: Yes. It's a pattern. If you want to write a pattern book, it has to have at least 20.

Shane Hastie: Who's the book for?

The book is targeted at anyone who facilitates collaborative meetings [18:44]

Aino Corry: Well, initially the book was for the people coming to my talks because I was talking about retrospective anti-patterns and they kept asking, where can I read more about this? And I started making some blog posts in Danish, but I soon learned that that wasn't really helpful when you talked about it in Chicago. And then, I started writing the book for my audience so that they had something to look at.

Aino Corry: But now I've actually worked on the book for seven years. And every time I revisited the book, I put in some of the references to the things that I've read about psychology behind team building or trust or meeting facilitation or something like that.

Aino Corry: I think that everybody who is facilitating any meeting could benefit from reading this book, not just retrospective facilitators, even though that's what it's written for. But I think it has a broad audience actually.

Shane Hastie: If people want to continue the conversation. Where do they find you?

Aino Corry: Well, I am on LinkedIn and I'm on Twitter, and I have a website which has my email address. And it's pretty easy to Google my name because I don't think there's anybody else in the world called Aino Corry.

Shane Hastie: And I thank you so much for taking the time to talk to us today. It was really good.

Aino Corry: Thank you, Shane. It was nice to talk to you again and good luck with your retrospectives everybody.

Mentioned

• QCon
• Book: Retrospective Anti-patterns
• Metadeveloper
• Gang of Four book – Design Patterns
• Norman Kerth – Project Retrospectives
• Equal Experts icebreaker cards
• Aino on Twitter and LinkedIn