Aino Corry

Speaker: Milan Bajic  00:36

Who is Speaker: Aino Corry? What’s your journey? How did you get into this Agile world? How did you learn about the agile, maybe we can start with that?

Speaker: Aino Corry  00:50

Well, I sort of stumbled upon the Agile. It’s difficult to make that journey short. So I always wanted to be a teacher in mathematics, because I thought the world needed better teachers in mathematics so I wanted to be a teacher in primary and secondary school. But then I hated to be in primary and secondary school myself, so I thought maybe I should be a high school teacher instead. I studied at the university to become a high school teacher in mathematics. But then I had to learn programming as part of the mathematics course, that was the beginning of the 90s. I didn’t know what programming was, I didn’t have a computer, but I really liked it. I really like programming is very, very interesting and satisfying to program. So I ended up doing the masters in Computer Science and the minor in Maths for teaching in high school.

When I finished my masters thesis, I really wanted to continue working on what I was working on, which was to sign patents and language constructs in object oriented languages. So I started a PhD to continue to work on that and I finished my PhD and I thought that I wanted to be a university teacher in computer science and I already started teaching at the university. But then I was headhunted to industry and it just happened to be a company in Denmark, a small company called Eos, that’s not a trifle that work together with Kent Beck on extreme programming right in the beginning of extreme programming. And they made these special tables for pair programming and things like that. So you could say, from day one, when I came out in industry and started as a developer, it was just agile development. I never really tried anything else. That being said, the first course I taught was actually in RUP, the Rational Unified Process, which is definitely not Agile. I taught that with only ever having tried agile, so that was weird. But that’s how I stumbled upon Agile and then I was working on different things like development and inviting speakers to conferences and teaching object oriented analysis and design and Java programming, software architecture design patterns. Then I saw a presentation with Linda Rising about retrospectives and I liked that and then I focused on that. I guess that’s my choice.

Speaker: Milan Bajic  03:30

Nice.. So what do you think, I mean, what you just mentioned about some of the aspects of extreme programming, even today, like kids are learning and it’s pretty, in a sense, natural for them. But when we look back 10, 15, 20 years ago, that wasn’t the case. What are some of the things when you work with developers? How should developers be working, maybe the question is not how but what do you see like the divide between the younger generations of you assume you’re a full stack developer versus what we see with older generations is maybe like, I’m a specialist in this specific application or for backend piece of it. Yeah. How do we get these to align?

Speaker: Aino Corry  04:30

It’s not easy, is it? Because previously, it was all about being a specialist. And having that job security and you being the one who knows how to change the system, this legacy software is yours. And whenever there’s any support needed, it’s your job, right? So it’s job security for you. Some people thought like that, and then come these new waves. And I sort of zoom into a company and I talk about track numbers and I talk about pair programming and maybe even mob programming and their like, it’s such a waste of time, it’s better the expert just does this. But then the expert is sick two weeks or on vacation and then we’re sort of in a problem. So I think it’s definitely something that people have to learn that sharing knowledge and learning and getting the track number down is really important for the long run. I understand that in the short run, if you look like one month or two months ahead, it’s pretty obvious that it’s really convenient to have somebody who can just code this with the experience that they have. There are two major problems with that one problem is that, what about the novices? What about the newcomers? How are they supposed to learn if you sort of keep it tight to yourself? And the second problem is also well, what if you’re wrong, right? What if the beautiful thing that you made actually is flawed? Maybe you should have somebody to look at it. Maybe somebody could make some tests that could reveal something you never thought about. But I guess that’s part of the problem. That what if it turns out that one of the things that I made isn’t really 100% perfect, so maybe I don’t want people to look at it. So it’s definitely clashing. But I have to say it’s not just the young and the old. It’s also something about personality, I definitely see some of the young novices in this field, who do not want to do pair programming, because they think it’s better if I just have this on my own, I own this software and I just work on this. So that shared ownership of software, with extreme programming is kind of difficult to explain. And I think especially to newcomers, because they haven’t felt the pain of the problems that can come out of being siloed is the problem.

Speaker: Milan Bajic  07:03

But also at least my experience has been, people are resistant until they try it. And they a lot of times change their opinion about either paper, especially mob programming. For a lot of people, it’s just doesn’t make any sense. This is crazy. Yeah. So have you seen that too, where it’s like?

Speaker: Aino Corry  07:27

Yeah, definitely so. I always try to introduce mob programming. Pair program is what people mostly know, but mob programming, I think it’s so productive and it’s so interesting. I always try to introduce it to the companies that I’m a consultant for and in the beginning is always like, people who are not developers should actually touch the keyboard, really, I mean, shouldn’t I be the only one who’s programming here. So in the beginning they don’t get the point and they don’t think it’s a good idea that everybody, maybe we should explain what programming, everybody is in the same room looking at the same screen only having one keyboard, and they share the keyboard, and everybody has seven to 10 minutes at the keyboard, even those who don’t program normally. And when you’re at the keyboard, you don’t have to do any thinking, the crowd around you should tell you what to do and help you through it. So even if you don’t know how to do this, you can just relax because people will tell you how to do it, and even how to make those weird symbols on your keyboard. You don’t have to think about that. So people are worried that it’ll be a waste of time. But I have to say that in the places where I introduced mob programming, and I said, let’s just try it out. We don’t have to change the way you working. But let’s just try it out as an experiment. Mostly, they’ve liked it. Of course, I’ve had some teams who just didn’t like it. And also if they chose, okay, we got this list of bugs, we need to debug. That’s great for mob programming, we can get that done. No, that’s not really the point. I mean, it’s better if you have a new feature you want to develop or an idea you want to try is much better for that. So if you can make people try it out on a new feature, or something that gives value to the users that will give you the most feedback, the most positive feedback as a staff. So take that as an experiment. And then once they try it, they notice this is actually brilliant. It’s fun. And you don’t have to wait for the architect to answer, you don’t have to wait for the data analyst, you don’t have to wait for the UX or the UI person. They’re just in the room. So all that waiting for each other you just eliminate that and you can just work together so once they notice that then normally they like it. What’s your experience Miljan about this?

Speaker: Milan Bajic  09:54

Well, it’s just in general that as a coach and trying to help teams understand, there’s a lot of times people confuse being busy with getting stuff done. And a lot of times, it just when you expose the whole kind of system to itself or the whole end to end process, people start realizing, oh, yeah, holy crap, this is not what I was thinking. And as you know, in Agile and in Scrum, we look at it from a customer perspective. So I think when people see in the quality perspective, when we see people appearing, it’s about learning, it’s about being vulnerable, right? Trusting each other. That really a lot of times it’s about that trust and creating a team rather than just group of people and individuals that do their own job within that team. That’s been my experience in the sense of just how powerful it is when it comes to developing teams that actually like working with each other. And they’re looking forward to pair programming with another person because they know they’ll learn.

Speaker: Aino Corry  11:07

Yes exactly. But it’s sort of a circle because you learn to trust each other by doing pair programming and mob programming. But you can’t really start doing pair programming or mob programming before you have a certain level of trust. It’s a circle like that. But once you get the circle started, it really evolves.

Speaker: Milan Bajic  11:27

If you think about it from a vulnerability standpoint, a lot of times we talk about how you develop trust is being vulnerable. So if you’re a junior guy, and you have a senior developer, or maybe you’re both senior, but you don’t want to expose them, you’re going to say, all my things, I’ll look bad, whatever it is, right? There’s some fear, and actually letting go of that fear and just sitting down with somebody and sharing and exposing in a sense, like how you do things or whatever your opinions on certain things, or how you solve that problem can help with that. Yes, definitely. You’ve written a book on agile retrospectives or retrospectives anti-patterns. There we go. How did you get into facilitation because obviously, one big part of retrospectives is facilitation.

Speaker: Aino Corry  12:29

Yeah, it is. I guess I always facilitated a little bit, because I’m an older sister in the family of a lot of people. So I guess that facilitation was sort of inbred with my childhood. And mediating and things like that. But the retrospective spark came with a presentation by Linda Rising that I watched in Denmark many years ago. And she brought this book by Norman Kerth called Project retrospectives. And she gave me that book, and it was just bedded cover to cover. And it was really inspiring. And I thought, Wow, can you do something like that? Can you actually make people share and appreciate each other and learn and come up with small changes for the good of the team. And I started facilitating retrospectives. And then Diana Larsen, Esther Derby’s book came out about Agile retrospectives. And I started doing those retrospectives. And I took a course with t Diana Larsen taught the course with her. So I just made more and more retrospectives. And I just got really excited about the retrospective structure that you have set aside time for reflection in the team, in order to find something that you together can help improve the team, instead of finding a scapegoat on the faults, you try to figure out how can we improve as a team. And I think that, it’s team building and it’s fun. And it’s really important, and it’s strengthening for a team to do these retrospectives. It’s really important. And I have seen so many retrospective really help people also seen a lot of retrospectives go really bad. Which is my book is called retrospectives anti patterns because it’s, how can it go wrong?

Speaker: Milan Bajic  14:27

Yeah, exactly. And I think, in a sense, the retrospectives are the core of lean thinking, it’s like, how do we get better? How do we relentlessly improve? And a lot of times there’s not that buying from the whole team, in the sense of some of the anti-patterns that you’ve described are exactly that. So maybe we can look at couple of works, some of those anti-patterns. Could you maybe talk about the prime directive ignorance anti-pattern and share with us what is that anti-pattern?

Speaker: Aino Corry  15:04

I hope you choose them. So the prime directive ignorance is we go back to the original book by Norman Kerth project retrospectives, where he wrote the brand directive for retrospectives, which is a long text basically saying, “Remember, everybody did the best they could”. And it’s that mindset that’s so important to bring to a retrospective, but it’s difficult. So you have to think when you enter a retrospective, okay, we know that in this team, in this sprint, in this project, some things have not gone as good as we hoped for. some people maybe have made mistakes, or have blundered or have forgot to do something. But what we need to figure out now is why did this happen and how can we support everybody in the team so that it doesn’t happen again.

But the problem is that we’re sort of brought up with finding a scapegoat. Like, when we were children our parents would ask who started that fight, who broke that glass and things like that. So we are brought up with trying to figure out who is the culprit here? Who can we attack and put into jail or something like that, instead of trying to figure out, what’s the problem here? How can we change the way this team works together? And the prime directive ignorance is because when you enter a retrospective, you’re supposed to, as a facilitator, really and truly believe that everybody did the best they could, but also, impart to the team. Remember that, you have to have the mindset that everybody truly did the best they could. But then there are some people who will say, I don’t think everybody did the best they could, I mean, somebody were lazy, somebody slack. And I know that even myself, I don’t do the best I can always. So it’s about having the courage as a facilitator to say, when we enter this retrospective, you should strive to have that mindset that everybody did the best they could because if we don’t have that mindset, we’re trying to subconsciously find the scapegoat, and find the one that needs to be punished and that can be maybe fulfilling for you but it’s not very constructive for the team in the long run.

What’s constructive for the team in the long run, is trying to figure out how can we support this person or these people, so that this will be better in the long run. And that prime directive ignorance anti-pattern is that, the facilitator chooses to ignore the prime directive and not talk to the team about it before they start the retrospective. And in all my anti-patterns, there’s refactor solution, and the refactor solution here is, bring the prime directive to each retrospective. Either you have it on a board, if it’s in real life, or if it’s online, then write it in the email, or at least say it at the beginning of the retrospective. Remember, we’re not trying to find a scapegoat, we’re trying to improve the system, which is us.

Speaker: Milan Bajic  18:03

Who along those lines, do you know, one of the things at least I experience with Scrum Masters or facilitators is that they’re not familiar with the role of neutrality in facilitation? Are you familiar with that? What are your thoughts? Can you say that getting the like is in a sense being neutral, when you’re showing, you know, neutrality and being biased, and that’s something that a lot of times they contribute by jumping in and then pausing maybe certain things or ideas,

Speaker: Aino Corry  18:39

It’s really difficult. It’s really difficult to stay neutral. But you have to, you have to be objective. As a facilitator, you’re supposed to just facilitate the team learning and facilitate the team decision making, and facilitate the communications and the discussion so that nobody leaves the retrospective feeling really bad about it and so that everybody leaves the retrospective feeling that they got something out of it. Now, sometimes as a facilitator, if the team is discussing a problem, and you know, if only they did this, it would be so much better. You have to try to hold yourself back and perhaps you can ask them if they want a suggestion, but you should, first and foremost, try to hold yourself back. And the reason being, that if you’re the one telling them what to do, then perhaps the motivation for doing it will not be as high as if it was something they came up with themselves. And I realized that the Toyota Kata that some people may have heard about, is something where it’s a bit like a retrospective, but it’s more controlled, in the sense that somebody perhaps together with the team, perhaps just choosing for the team chooses somewhere that they should be, this is like the star that is where we want, this is what we want to achieve. And then the Toyota Kata is Okay, so where are we? Are we here? Are we here? Are we here? And then we find the smallest action that can get us towards this without thinking that we will ever reach this. But what are the small actions, and some people prefer the Toyota kata when you can be more hands-on with helping them to say, this is where you should go. But I think it’s two different things. I think a retrospective should truly be where you as a facilitator are neutral and the team should figure out what they should talk about, what they should learn, and what they should do. If you want something else, call it something else. 

Speaker: Milan Bajic  20:41

Yeah, or just be aware. Like, in the sense, a lot of times the lack of awareness or understanding of this neutrality. So like, if you’re stepping in, you can say, Hey, guys, I’m putting on my non facilitator hat. Right? Yeah. And just be aware that you’re doing that versus just unknowingly imposing things or showing your bias.

Speaker: Aino Corry  21:04

Yeah, that Yeah, I agree. That’s also why is it? Sometimes you can ask them if they want input? Because if they don’t know how to do this, they can you can say, Well, do you? Do you want to hear what other people have tried? But as you say, it should be a conscious decision, instead of trying to manipulate them into something.

Speaker: Milan Bajic  21:24

Could you talk about your wheel of fortune anti-pattern, what’s that one about?

Speaker: Aino Corry  21:30

Yeah, so the Wheel of Fortune anti-pattern is, you should think about being in the Tivoli, or a fair, and there’s this wheel of fortune, and the Game Master turns the wheel of fortune, and if it hits these three numbers, you won, and if it hits any of the others, you’ve lost. But if you hit the one where you want, you can choose a little teddy bear or some candy or something like that. And all the others, you just lost your money. So that’s why it’s called a wheel of fortune.

Speaker: Milan Bajic  21:58

Hit or miss?

Speaker: Aino Corry  22:00

Yes, mostly miss. So in a retrospective, sometimes people feel well, we don’t have a lot of time for this, because coding is what we should really do, that’s the real work. So let’s just rush through the retrospective as fast as possible, right? They say, well, the quickest thing is to just put up three posters and say, what should we start doing? What should we stop doing? What should we continue doing? And then the team members, they write these post and notes, and they put them up on what should we start, what should we stop, what should we continue doing. And then sometimes you see something like, well, on the start, we should definitely start having pair programming and on the stop is, we should have less meetings or something like that. And then if you really want to rush the retrospective, then you just say, Okay, if we need to have more pair programming, we just make the Action Point is we’ll make a schedule, while you have pair programming three hours a day, three days a week. And that fixes it. And for the less meetings, we’ll just cut away half of the meetings, and then we’ll be fine. And then everybody leaves the retrospectives and they’re happy. But the problem is that sometimes these things that you see are only symptoms of problems, they’re not the actual problems. So if you solve the symptoms, the problem is still there. For instance, in the in the pair programming one, if the problem really was that people forgot to do pair programming, then surely a schedule would work, a schedule would solve the problem. But if the lack of pair programming is a symptom of something else, for instance, a symptom, that there’s a lack of trust in the team, as we talked about before, people feel uneasy having other people looking at them when they code, then scheduling the pair programming doesn’t really change anything, right? It just…

Speaker: Milan Bajic  23:56

Yes, just add more attention to it…

Speaker: Aino Corry  24:00

Yes, it would be even worse. And with the less meetings, if you just cut away some of the meetings, you think, oh, we can easily solve this. And perhaps it’s not the quantity of the meetings, but the quality of the meetings, maybe it’s just a symptom that the meetings are bad, they’re badly led, there’s not a good agenda, the wrong people being invited, things like that. Maybe you should think about these things before you jump to conclusion. So the Wheel of Fortune is where you go directly from the gathering data to deciding what to do instead of having that really important part in between which is generating insights about the data.

Speaker: Milan Bajic  24:42

I know you talk about the pro version and convergent and it’s the groan zone, right that you’re talking about him being

Speaker: Aino Corry  24:51

Yeah. You need to have this groan zone open where you can talk about why did this happen? What is causing this? Could this happen again? How often does it happen? All these things you have to look at before you start running into action and solving things. But often I see, actually today just a few hours ago, facilitating a retrospective with developers and asking them to gather data about things that went wrong and they write the solutions directly. They don’t even mention the problem, we should start doing this. Why should we start doing this? So we had to start with why?

Speaker: Milan Bajic  25:34

I mean, that’s probably the anti-pattern or anti-patterns in the sense of it’s the mindset of relentless improvement and understanding what goes into relentless improvements, not just oh, yeah, this is it. Let’s jump into it.. But like you said, it’s like really understanding the why, and being able to spend at least some time exploring that area, rather than just jumping to conclusion, and then having a team commitment to fixing these things and exploring these things. I think that if I reflect back and facilitating retrospectives, or just in general, at least in my opinion, that’s the mother of all anti-patterns when it comes to retrospectives.

Speaker: Aino Corry  26:22

Definitely, yeah, just jumping to conclusions and it’s so easy to do.

Speaker: Milan Bajic  26:29

Also, we live in an environment where we don’t have time, we’ll just keep moving, do it fast. And sometimes, I joke around, but it’s almost like marinating things, sometimes it’s good to marinate things and let us sit and discuss it because something much better comes out of it.

Speaker: Aino Corry  26:50

Yeah, and I often see that we’re in the retrospective, and people start talking about one of the things, one of the incidents, and they want to end the conversation, and I start saying well, what caused this? And they say, oh, but what else could have caused this? I mean, you could do the fishbone diagram to find that out but you can also just ask the question, and I can feel in the beginning that, why is she stopping us? Because we’re so close to the conclusion, we’re so close to the solution. And I’m trying to still okay, so, but why are we here? What happened? How did we end here? And then they reach a point at some point where it’s like, oh, yeah, yes, that’s right. Yeah, it was actually, because we hadn’t talked about that before, or we didn’t know who was responsible for that or, oh, we were both responsible for that. But I thought you did it and things like that. As you say, it’s a marinating thing but brains are slow sometimes and it takes time to go back to that reflection state where you can actually really understand why things have happened. Because you’re so focused on the solution always.

Speaker: Milan Bajic  28:07

It is but especially developers should know that. As a developer, you know that it’s rare that you can just sit down and just solve a problem. Unless you’re in the state of flow. Usually, you’re thinking about it when you’re riding, walking, it marinates in your head as far as how you’re going to solve this problem so it’s similar. Like the problems that we’re talking about in retrospectives are just different types of problems but they’re still problems. So that should be familiar to people that are solving problems.

Speaker: Aino Corry  28:43

I think you’re putting the finger on the point there because it’s different kinds of problems. And I think that the developers, they appreciate that programming is hard and it takes time to figure that out. It’s only in the shower, as you say, in the long walk that suddenly it occurs to you or maybe in your dreams. But I think the one of the things that I’m trying to make them understand is that all problems are actually hard. Also, just people problems like soft problems actually also really hard problems about how to communicate, how to give feedback, how to trust each other, it’s really hard. And it takes a while to think about it and to reflect in order to find the right solution.

Speaker: Milan Bajic  29:34

How is this related to do it yourself anti-pattern?

Speaker: Aino Corry  29:40

Yeah, so do it yourself anti-pattern is a person that sort of explains the anti-pattern solution is that, it’s always the same person who is facilitating the retrospective and in Scrum, it’s often the scrum master who is the one facilitating the retrospective every time And the problem is that when you’re on a facilitator, you’re really busy. Like you have a schedule, and you’ve written down maybe some points about things that it would be nice to touch upon. So maybe you can ask these questions and you have to look at people’s body language. And it’s even harder now when it’s online, because you can only see the face and sometimes the hands. 

Speaker: Milan Bajic  30:24

You’re lucky. I don’t know, sometimes it’s difficult to get even people to turn on their cameras.

Speaker: Aino Corry  30:33

Yeah, got some issues about that. I can come back to that later because I agree. That’s actually a different anti-pattern called peekaboo. But the do it yourself is that if, you are doing the retrospectives facilitation yourself every time for your team, then either you can choose to be the facilitator and then you don’t really get a retrospective as a team member, or you can choose to also be a team member but then you’re not as good a facilitator, because a facilitator is really hard job that you have to really focus on everything people write, everything they say, every little movement, and the agenda, the time, you have to make sure that you go through all the important stuff and then you come up with action points at the end, instead of dragging it on half an hour later. So do it yourself is try to not always have the same person facilitating, or at least not having the same person from the same team facilitating because if you’re in a team, you’d like to be in the retrospective yourself.

So maybe you can swap with another team and you can help facilitating each other’s or within the organization, or you can have an external facilitator. But the thing you said about the video is really important as well because a lot of people are not on video. So in the beginning of COVID, it became really, really important for me to have people being on video because all the retrospectives were online. Previously, perhaps a half of the retrospectives I facilitated were online, but the people who were online then, they knew how to work remotely, and then you it was important to be on video. But now everybody had to do that. And a lot of people didn’t want to do that. I want to just say, let’s just force everybody to be on video but then I heard the people backlash of people saying you can’t force people to be on video, maybe it’s psychologically unsafe to them to be on video. And I say, Okay, I appreciate that. To some people, very few. it feels very bad for them to be on video. But I think again, like in the Wheel of Fortune, we have to think about what’s the difference between the symptoms and the problems.

The symptom that we see is that they’re not on video. What’s the problem? Let’s find out what the problem is, before we start solving symptom. I mean, you can do all sorts of things with the symptom, you can enforce that they’re on video, or you can say, let’s have a game in the beginning where everybody show something red from the office or find something blue or something like that. And that makes them turn on the video, and then it’s easier to have the video turned on. But if they continue to not be on video, then I think you have to figure out what is the problem behind this. And then for the people that I’ve asked, I’ve had different excuses or like presentations of what the problem is some people say, oh, I don’t have a webcam. I mean, that’s easily fixed. If that’s actually the problem, we can very easily buy you a cheap webcam, which will be sufficient for being in a retrospective. But then if you tell them that they’ll say oh, it’s okay. I, I’m fine with this, because I’m actually taking the meeting from a car. And you’re like, okay, so the lack of video is a symptom of a problem that you don’t take this retrospective really seriously.

Because if you take a retrospective seriously, you don’t do it from the car. Because a retrospective is a is a time that you set aside to really learn about your other team members. And you’re probably having some sort of shared document online that you’re supposed to be able to write into and look at. And you can’t do that while you’re driving a car. And you also can’t look at the other people in the team while you’re saying something and see their reaction while you’re driving the car. So if that’s the problem, then that’s just a symptom that the problem is they’re not taking it seriously enough. And also when they say it’s because I’m in a café, I’m taking it from Café. Okay, well, then that’s another problem. You’re not taking it seriously.

Speaker: Milan Bajic  34:49

Change the time maybe or something like that. A lot of times people are in different time zones. It’s too early for me, I don’t want to wake up my, so I’m just listening and turning off my camera, maybe because it’s dark, and I don’t look good, whatever it is, right? I agree with that. It’s just finding the underlying reason or maybe it’s a new team and whatever it is, I don’t like how I look in the morning, and it’s winnable from that standpoint.

Speaker: Aino Corry  35:24

Exactly. Fair enough, then we’ll deal with that.

Speaker: Milan Bajic  35:29

I saw your talk. I think it’s maybe a couple of years, importance of laughter. I wanted to talk to you about that. Could you elaborate on that idea of importance of laughter?

Speaker: Aino Corry  35:46

Yeah. I always try when I’m facilitating retrospective, any meeting, actually, to make people laugh for several reasons. It just makes you feel good when you’re laughing, and feeling good is always a good start of a meeting. But also, if there’s any tension in the meeting, which often is in the retrospective, then laughter is a very good tension release. So if everybody laughs, then we can start talking about things. But also, if you’re asking a question, and it’s completely quiet, nobody knows what to say, it’s probably because the brain is just a bit stuck from the tension. But if you can make people laugh, it relaxes them and it allows the brains to think about it while they’re laughing. And then probably, they can come up with something. It’s also because in my experience, the team that laughs together, is a good team. I’m not thinking about if they laugh at one of the people in the team, of course, but if they laugh together, it’s a very good way of gelling the team members together. So I think that, among other things, there’s a lot of importance in laughter. And if you’re not funny, as a person, you can find some funny cartoon and show or a funny video clip and show, it doesn’t matter. You can just steal and rob and lend. You don’t have to be funny to make people laugh. And I think it’s really important for everybody to do that.

Speaker: Milan Bajic  37:15

Yeah, I mean, if you reflect on any team that you’ve been on, that you really liked, that you’re like, this definitely felt like a team, definitely a lot of laughter, a lot of jokes and your expense jokes and other people’s expense. And I think that’s part of that trust, right? Like, if we laugh together, in some ways we’re developing that trust, or we have that trust, right.

Speaker: Aino Corry  37:45

I don’t mind playing the clown a bit as a facilitator. I don’t mind doing something stupid. It’s easier when it’s in real life, because I’m really stupidly clumsy. So I always fall off something or not something so and then we can laugh about that. And then when I’ve been silly, everybody else can be silly. So it also takes a bit of the seriousness away. And I think actually, we take ourselves too seriously. Why do we have to be so adult and serious in order to be important? Why can’t we be childish and have fun? I would like that.

Speaker: Milan Bajic  38:17

Yeah, it’s a good question. You know, in a sense, like in I think all of us have that child in them, that wants to have fun that wants to laugh. But I don’t know if it’s conditioning over the years that like, you’re serious about work. You’re all it’s all business, that the expectation and part of the culture, and how we behave becomes a norm.

Speaker: Aino Corry  38:44

It doesn’t mean think about me young. When was last time you laughed so hard that your stomach hurt?

Speaker: Milan Bajic  38:51

Yeah, I don’t know.

Speaker: Aino Corry  38:53

If you remember that feeling, don’t you?

Speaker: Milan Bajic  38:55

Yeah. I can. It’s a good question. That’s a really, I don’t know. I can think of a couple of times, it’s usually on my own expense too with other people that I trust or something in common that we have. But yeah, that’s a good litmus test against you know, (inaudible 39:19)

Speaker: Aino Corry  39:20

I don’t know if it’s a good team, that you’ve heard. I’m not sure that’s a litmus test, but just thinking about it. Laugh today. It’s good.

Speaker: Milan Bajic  39:29

Yeah. I don’t have any meetings after this and it’s like, it’s setting me in the right mood. On the East Coast here, it’s still morning. So there’s something to be said about, just the mood that puts you in and it’s not just short term, but it might be like if we’re laughing and having a good time as a team, we might be even more productive, right?

Speaker: Aino Corry  39:55

Yeah and you can start by laughing at something silly and then you laugh and then you know, the smile lingers on your face after the laugh. And that smile sort of sends signals back to your brain that you’re happy and that okay, well, I’m happy apparently. And then you become happy and optimistic. And if you’re happy and optimistic, you are more resilient to problems, so you work better. So actually the bottom line in every organization is improved if people laugh every day.