 Then I'll introduce the talk and then I'll actually do the talk and afterwards. I'll tell you what I said So if you should drop off at some point, it's okay. I mean, I'll do a recap in the end so my name is I know Corey and I used to be a developer, but I'm not anymore now I'm what I call a meta developer because I'm facilitating meetings for developers I'm teaching developers. I've been teaching at university and in industry and I'm putting together conferences much like this But at other parts of the world. So I'm not a developer, but I'm developing developers and thus I'm a meta developer. I Come from a country called Denmark. How many of you have been to Denmark? Oh Some of you have been to Denmark. So you know that it's it's quite far away from here And you can see so the Google Maps are showing them my son is is at home in Denmark right now and we're All the way over here and I arrived at three o'clock last night So luckily the jet lag hasn't started yet. I have simply no idea where I am or what time it is So if I fall asleep, please somebody wake me up and I want to tell you what it looks like in Denmark So this is I think from a tourist brochure We've got beaches all over because we're a small country in middle of the ocean Not many people six million people and it's just beaches everywhere But if you actually live in Denmark, you know, that's not exactly what it looks like So if you live in Denmark, it's mostly like this cycling in the snow. How many of you tried that cycling in the snow? Yeah, Dave has as well. It's not the most pleasant thing in the world, but it gets you from A to B so that was a little bit about myself and I'm doing this talk about Anti-patterns for retrospectives because I've been facilitating retrospectives for something like 10 years and What I noticed was that I kept making the same mistakes over and over again And it's a bit ironic that I didn't really learn from these mistakes since I was facilitating retrospectives, right? But let's not delve into that But I've started learning now from my mistakes and I've seen that there are some patterns of things that come over and over In my retrospectives, but other also in other people's retrospectives So the point of this talk is to create better retrospectives by awareness of anti-patterns And I'll come into later what an anti-pattern is So what I want you to have is better retrospective a more fun retrospective or at least Less painful retrospectives. That's my goal with this talk and I have chosen six Anti-patterns for retrospectives and is if any of you were at my talk about distributed retrospectives two years ago And I yelled India There's two of them you've seen before and I wondered whether I should take them out and replace them with others But on the other hand, they're very important and it's two years ago So you're probably most likely forgotten in any way. So I they're here and I want to tell you as I said what an anti-pattern is so I've brought with you an example of an anti-pattern the first anti-pattern I heard of and It's something to do with the programming in object orientation So I hope that some of you at least know something about programming in an object-oriented language Otherwise, you can just shut down for a while and I'll tell you when to come back So an example of an anti-pattern first, you have like the context or the problem. Where are you right now? Where were you when this problem arrived? So you need to figure out where to place the functionality of the class That's always the thing that you're thinking about when you're doing a good design Where do I put this functionality? Which class does it belong to and Then the forces are the things like in the reality that that draws you in this direction or this direction so they're different Reasons for choosing one or the other so you're using object orientation But another force is you might be experienced in imperative or functional programming So perhaps the ways that you solve problems come from a different field and The anti-pattern solution which is the bad solution that you've normally just jumped to is that you play all of your methods Put all of your methods in your favorite class and that becomes the heart of the architecture and the problem with that The problem with that anti-pattern solution or the consequences is that your class will become extremely big Which is not a problem in itself apart from the fact that it's difficult to read But also that it'll be difficult to understand and maintain afterwards. So that's a problem that you get That's the anti-pattern solution and Just to illustrate this pattern anti-pattern is called the blob. I don't know if any of you saw the sci-fi Scary movie like 30 or 40 years ago called the blob But it was about a big jelly thing coming down from outer space and it would suck everything into it So if it touched something that would become part of the blob if it touched tree That would become part of the blob if it touched Dave Farley He would become part of the blob and that is sort of to illustrate what that class in your system would be It would be a blob. It would suck up everything So What do you do then if you have the blob you just quit your job run somewhere else change the log file So it doesn't pass your name on it or something like that. No, there's actually things you can do about it That's what we call a refactored solution and that I think is the beauty of anti-patterns It's not just you did this wrong, but there's also a refactored solution I have to admit that sometimes the refactored solution is actually to change jobs But that is not any of the solutions. I'm doing today. So refactored the class by merging the methods into other classes and The strategy is for that is that you use hygration and low-coupling. There's some books for that But now it's known as microservices. So a lot of people will do that now They will take a big blob of legacy code and they'll create microservices out of it So actually the blob is is the anti-pattern for microservices the benefits and drawbacks is you have smaller classes Which are easier to maintain and easier to get an overview of it'll take some time to refactor it But the trade-offs is it'll be worth the time So to illustrate this I just pulled out this old picture from the anti-patterns book That tells you that instead of having like this huge class you just take Things out and put them in different smaller classes or microservices if you wish So that was my attempt to explain what an anti-pattern is because some people just think that's very negative to have an anti-pattern But the refacted solution is an important part of it Now I want to tell you a story about a Danish company called Titanic AS it creates reliable navigation software for ships and We have a small team in this in this company. We've got Peter, Nikki, Susan, Jim, Sarah and Robert and Titanic has had some problems with its clients and some of them are complaining about the navigational software in the ships There's been some accidents and then they of course want to do agile They want to make things better So they they send everybody off on the Scrum Master course and then they need to figure out who should be the Scrum Master and then Sarah Sarah is the one who is mostly interested in this so she is becoming the Scrum Master so we now have a small team with a Scrum Master called Sarah and What happens then Sarah is about to facilitate her first retrospective because she's a Scrum Master and she has she's read the book about Project retrospectives by Norm Curth and in that book We've got something called the the prime directive of retrospectives So the regardless of what we discover we must understand and truly believe that everyone did the best job here She could given what was known at the time is her skills and abilities the resources available and the situation at hand That's what Norm Curth said that you should think about whenever you start a retrospective Unfortunately for Sarah. She's doing retrospectives for developers and some of these developers Does not have that mindset when they go into the retrospective Some of them are thinking. Hmm. Actually he is an idiot or She just ruined that or they have been very lazy and they definitely did not do the best they could So we need a scapegoat to point fingers at and she knows this So she doesn't want to talk about the prime directive because she's worried if she says something about the prime directive That these developers will think that this is just a lot of bs It's just Feely feely touchy stuff and that's really ridiculous. So she doesn't mention the prime directive And that leads us to the antipattern called prime directive ignorance And what happens with prime directive ignorance is that if you don't even believe that the prime directive is a good idea Then you will definitely fail So, um Yeah, I tried to make a joke. Thank you for somebody and laughing and it was very very polite of you So the the point of this prime directive ignorant Antipattern is that the the problem is that it feels awkward to follow the directive It feels awkward sometimes even for the facilitators to say that people should follow the directive because he or she knows that people will Not think that everybody did their best And then what happens in this antipattern is that you just forget about it You don't mention it. You don't say anything about it. You just start the retrospective like you always do But the consequences are that people will bring all their assumptions and negative expectations to the retrospective They will not have the right mindset necessarily some of them do of course, but not everybody does and there's no focus On having the right mindset Because they're so eager to find failures. They're so eager to find mistakes. They're so eager to find scapegoats And the anecdotal evidence is that people do not really listen And in the end people will become afraid to go to the retrospectives or to say anything that's important at the retrospectives And then the refactored solution of course obviously is to bring the directive to each retrospective in some way And i'm not necessarily saying that you should put this on the wall But for instance in the email you could remind people about it when you invite them or you could say it at the beginning of the retrospective Remember that we're not trying to find scapegoats. Remember that we have this mindset That we expect that everybody did the best they could because if you look at what people actually did and the mistakes that happened It's not It's often not because the people are evil. It's because they had problems There was something that didn't know there was somebody that didn't have the skill set that they needed and and what I see Often is if if the prime directive is part of not just the retrospective, but the whole organization the organization is a very nice place to be I I definitely can remember differences between having A manager who did not believe in this prime directive and a manager who did believe in this prime directive I remember making huge mistakes and one manager would tell me off But another manager would say that's very interesting. Thank you for telling me. Let's look at the system And the first time that happened to me. I was surprised. I thought I'd get told off But he just said that's very interesting. Let's figure out what information you had at the time Let's figure out what skills you had how we can do things differently So creating a learning experience out of failure and now I want you to try something Think about this for 20 seconds the prime directive and whether it is a problem where you are in your retrospective Just think about it on your own for 20 seconds And I'll talk to your neighbor unless you're shy and would rather just play with your phone So if you sit with your phone your neighbor won't talk to you But please just spend a minute talking to your neighbor or neighbors about this whether it's a problem for you in your organization So Right some some of you knows this game that when you see me raise my hand and you're quiet and you raise your hand Thank you very much for For working along in this This is different from Denmark, right? I mean people don't like to talk to each other in Denmark This is beautiful. I like this But perhaps I didn't prepare well enough. I'll bring some belts next time So, um, is there anybody who'd like to share just one or two? Is it a problem? Yes, please And yeah, sounds very good. Thank you for sharing anybody else who wants to So That's a good point They want to be very nice to each other to the extent that they're sugar coating. Yeah, not a problem in Denmark. We're very rude But I can I can sense that it's a problem here. You're all very polite But so yeah, do you want to say something? Oh, sorry Yeah What exactly they should do And how we progress what we did wrong So they can go through each and every question So we really went in a Anti pattern of It's better now. Good. Yeah that sort of Feeds back feeds forward to one of the antipatterns that will come later in this tool Did you want to say something as well there in the back? Yeah, and that's good Sorry To to avoid the failures. Yeah. Well, I think the only way to avoid failures is is to learn from what's happening And then change things the next time depends a lot on the failure, of course I think one problem that I see is often that the communication is Is not that easy. It could be because of the sugar coating They don't want to point out things that are problems But it could also be that they perhaps they've seen some retrospectives that doesn't work and then they say well Who cares? Why why do we why do we want to talk about things that's important to us? If it's just the same over and over again And I'll be coming back to those issues during the talk Yeah Well, that's a whole different talk I think actually you could find my talk about distributed retrospectives from two years ago online And I have a blog post about we might have time later, but I'll be here for three days So yeah, I find that very interesting and I agree. It is it is problematic. Yeah Right So what you just did was an example of something called think pair share that I use a lot in my teaching But I also use it at retrospectives You probably notice sometimes if people ask a question to a lot of people They'll it'll only be the extroverts and the active thinkers who will be answering because they Well, some of them think very fast Some of them just don't bother to think before they answer You probably know the the situation and then we have the people who are more reflective or introvert and you never hear their voices So think pair shares just a pattern that I use in retrospectives or talks or Or teaching where people have a time to think on their own to reflect and talk to somebody in a way that it's It's fairly safe because it's only two and then people can choose to share if they want to So that was just an extra thing So after four weeks sarah is doing the next retrospective and she took the scrum master course as I said And I think according to your comment down there She learned a way to do it and the learn the way to do it was What should we start doing what should we start doing what should we do more of less of etc? And to me that is actually Or it can be an anti pattern that I call the the wheel of fortune And the reason why I called the wheel of fortune is that If if you're just saying what should we start doing what should we stop doing which we do more or for less of Sometimes what you're looking at is actually just symptoms of the actual problems So for instance, it could be we should we should do more pair programming or something like that And and then that's uh, well that's supposed to know that put up in the start and everybody dot loads And that is the one that we'll have so that'll be our action point that'll be more pair programming But if you didn't take the time to actually think about Is this actually a problem that we don't have enough or is it a symptom of another problem? It could be just that they don't have time to do pair programming And then it's a problem and then that solution is great But it could also be that people are very introvert That they haven't found a way to do pair programming in a way that helped them or made them feel safe And then just ordering them to do more pair programming will not solve the problem Because the problem is different And this is just a symptom and you could probably think about other things that actually just symptoms of problems And that's why I call the wheel of fortune because it's like just rolling this wheel of fortune And sometimes you're correct. This thing that you need to start start doing is actually the thing that you want to change But sometimes there's a story behind and you need to go into that story So let's look at the antipassant for the wheel of fortune Well, the problem as I said is we're all very busy and retrospectives take time from coding So let's do the 45 minute retrospective that you can learn about in in some old scrum master book or some other books Let's let's just do it as fast as we can if every just put up these posted notes We know exactly what to do more or for less of But the problem is That if you skip a two in the retrospective and I'll get back to what I meant with the a step or two in the retrospective If you skip that and you just get on with it You will actually have some really bad consequences Because as I tried to say before the problems that you find and suggest solutions for are only the symptoms of the real problems Not necessarily always But sometimes they are and then you're solving things and then at the next retrospective the same problem will come up again You'll have like a groundhog day retrospective It'll show its face in different ways because it is just symptoms of an underlying cause So what do you do? Well, what you do is that you remember the step called generating insights before you figure out what to do Because if you look at at Like the the life of a retrospective It's got five different phases and all five phases are very important But sometimes in order to skip things and just go back to the real work the coding You will just drop some things that are really important like setting the stage getting ready I always ask all the people in my retrospective to say something It could be something stupid. It could be what was your breakfast or how was your Christmas vacation? or How if you should describe this last spring does a weather forecast how it would be and these these questions seem stupid But what they do is actually two different things One is that all everybody is forced to say something and that means it's easier for them psychologically to say something later For the people who find it hard to say something if they're allowed to be silent from the beginning It's much easier for them to stay silent. So just demand everybody to say something And when it comes to distributed retrospectives, for instance If people are not co-located if they're not working together the thing about becoming a team or becoming good colleagues Is even more difficult not just for the retrospectives And I truly believe that in order to work well together you need trust And one of the things that gives you trust is to know something about each other So for these people who are distributed I ask them silly questions like what's the weather like where you are How was your breakfast or how do you celebrate? Christmas or what do you do in the weekend things about private things and in the beginning they'll be like I'm a developer. I don't really like to hear about my colleagues private life But they will laugh with each other and they'll learn about each other and it will build the trust that they need So I think that this even though it's a very small part of the retrospective is really important Then you gather data You look at what has happened that is part of the retro in the retrospective It could be a timeline like this one It could be what to do more of less of what to start doing stop doing not necessarily saying that that is a bad activity It's only bad if you skip the next step Because the next step is to generate insights to figure out Why did this happen? How is this affecting you? It could be like this line saying how do you feel right now? Did it give you energy? Did it take away your energy? Make people tell the stories behind and even if if there's something that's very important And you don't really know what it is You could use things like the fish bone or the five wise to actually really do some course analysis But it's very important and it's very very difficult and it's what people sometimes skip Because also as developers we are very good at solving things So whenever we see a problem, we just dive right into the solution And as a facilitator you need to open that field of communication And you shouldn't allow them to to to close it and to come up with solutions until they've spent some time in that Terrible terrible place where they actually don't know for sure what they're talking about But that's very difficult as a facilitator, but very important And then you decide what to do and then numerous ways of doing that could be brainstorming But what is important is that you have some sort of smart goal something that is specific Instead of just saying more pro pair programming It should be how much pair programming by whom When does it start and when do we evaluate whether this experiment actually work because instead of talking about changes as we also heard in the morning, you know Experiments are much easier for people to to accept And then you close the retrospective and that's also important It's important to say we started here. We gathered this data We had these discussions. We decided what to do and this is what we'll do and next time we have a retrospective We will look at the result of these experiments and we'll see whether they work or not whether this is something we'll implement And this is important for two reasons one reason is that oftentimes a retrospective they come up with action points and nobody looks at them So it's important to figure out who is responsible not for doing this But for making sure that this experiment actually takes place and to come up with the result And another thing is that sometimes I've experienced as a facilitator That sometimes the people in my retrospective think that I made all the decisions Oh, I I didn't do anything here. It was just a facilitator who told us what to do So to me it's very important to go through all the different steps and say you came from here and you went here and you did that on your own right More time goes Now sarah enters the anti-pattern death by postponement. I think that's a very good name for an anti-pattern death by postponement The problem is that you you notice a problem, right? Oh, there's a problem here with the test or there's a problem with the communication with the analysts or something like that and Your solution might be to just say well, we've got a retrospective coming up in a week Okay, we can talk about this at the retrospective because we've been told we've been trained that these are the places where you talk about problems So I just put it on a post-it note and I remember to talk about it in a week And of course the consequences is that the solution is delayed something that perhaps could have been solved today Is delayed to the next retrospective, but an added problem is that when you already At a retrospective sometimes there are so many things to talk about That if you if you talk about things that people already know it seems like a waste of time One of the things that I find really magical and interesting about retrospectives is when people share something and they get surprised They look at the timeline and they say I didn't know this happened When did this start working or why did this taste fail? Or are you going on maternity leave tomorrow? I mean, I've seen all sorts of things coming up at retrospectives and there should be a I borrowed this computer. I don't know why it's talking to us And the refactor solution is to raise the problem when it occurs Of course and use the retrospective as time to explore And what is the strategies of raising the problem when it occurs? It's something that I learned from the in the rising called real-time retrospectives or real-time timeline and this is a picture from From a team that I'm doing retrospectives for and what they have is a real-time timeline So in the office where they're sitting They have this timeline and they can put up posted notes if something is good or something is bad or they have questions about something Because I mean in the ideal world we wouldn't need any retrospectives people would just talk about things when they arise With the right people and we would solve it But it is not the ideal world yet and it is difficult sometimes to talk about failures It's difficult sometimes even to share that there was something you were happy about And these posted notes makes it Easier for most people because they can sort of put it on a piece of paper and it's not your feelings anymore People can look at it and move it around So a real-time timeline can make it easier for people to share how things are going on So I wanted to ask you this but I think we'll skip it because then we'll have more time in the end And then we'll move to the next retrospective. So Time is time is going and and saro is hearing things like we do not get enough out of the retrospective The time for coding is more important. They always blame me for this We can do it in half the time people are getting tired of the retrospectives. They think they're not efficient. They think they're boring So now we're in the anti-pattern called let's get it over with And I sometimes see at companies where they start with a one and a half hour retrospective Then it goes back to an hour and then it's 45 minutes and then you're asked Can you do it in 30 minutes? And then some people show up 10 minutes late and you have 20 minutes for the retrospective And of course if you're like 20 minutes for a retrospective with five phases that are equally important You might well not do it Then it definitely is a waste of time and then you're sort of shooting yourself in the foot as a facilitator if you're allowing that to happen But It's not easy. Let's look at the anti-pattern. So the problem is that the time for coding is more important That's often a problem. People say let's do some real work instead of all this talking and the posted notes The anti-pattern solution is that retrospective vanish They like they die little by little and in the end they're completely gone The consequences is that the time is saved but more time is wasted on not learning not having continuous improvement And the refactor solution is to restart them get new activities get an outside facilitator try something new But actually what I've learned works. The best is to ask questions Why do we have these retrospectives? What do you expect to get out of them? I'm sometimes at companies where the retrospective fatigue sets in and they say we're not getting anything out of it And then I'm looking in my little black book. I've got a little black book where I write down everything about retrospectives I write down the action points. I write down what happened with the action points I write down what people said what they discussed and then I make a retrospective about the retrospectives And I put down all the action points or the experiments that I wondered And then I asked them to look at how many of them did you actually do? And what was the consequence of doing it? Oh, yeah, we actually did change that. Yeah, we did Yeah, we did we did change that but we thought we just did that. Yeah, but that was part of the retrospective and then there are some things that they didn't do yet Like they didn't have time for it or it was something that was put down as an experiment But it was actually a long-term goal and then a long-term goal written down as an experiment You can't really expect that to happen in the two weeks And then you have to look at that So I do a retrospective over the retrospective That's one way to make them see that actually something came out of them to to make them understand that they are valuable to them Instead of just forcing people to do retrospectives. I think asking questions is better and making them look at the data And what happens now? Weeks pass The boss will never allow it. We always discuss the testing framework. Why can't the retrospectives help us? We never get anything changed again some sort of retrospective fatigue But in a in a different way this time they still like the retrospectives But they're not solving the right problems and it's the same problems coming up and up again And that's the antipattern that I call in the soup And the problem with being in the soup Is that you hear people saying well, we work on all we want to work on the big problems Not just the small problems about the coffee or how long the stand-up meetings should be But also you hear people saying we always discuss the same It's like a groundhog day. So the symptom is the same as for the earlier pattern And the antipattern solution is that the actions need management approval action And then we can't do anything about it. We're just like meh Well, why bother with retrospectives? All our problems are out of our hands And the consequences of course is that if management has different priorities Nothing happens and retrospectives degenerate into complaint sessions And sometimes letting out air is good and that's a good way of using a retrospective But there should also be some actions that changes things. Otherwise It will feel like a waste of time. So what do you do? Well, the refactor solution is stay out of the soup and come up with things that you can actually do something about Yeah? Sorry Oh, sorry Cultural reference misrepresented sorry groundhog day is is an old american movie Where a man wakes up each day to the same life because he's got some things he needs to learn And he keeps on making the same mistakes And everything happens the same way but gradually he's learning. Thank you for your question Sorry I should have thought about that. I thought everybody had seen groundhog day Well, you you should see it and it's a great movie So so the refactor solution to this problem and this is actually an activity I use Again and again and again and you probably know this in different in different states Change adapt accept. So I draw three circles on a board I say this is the circle of the things that you could do something about This is the circle of the things that you can influence And then out here we have the soup that you cannot do anything about apart from accepting its existence And I I use this activity both When they're just talking about the problems or the things that happened Just trying to make them think about Where do these problems belong but also actually later on in retrospective if they're brainstormed about things to do Like experiments or activities I forced them to put it into the soup Because sometimes if you come up with three activities that this team cannot do anything about Then when you ask them at the next retrospective what happened They have to say nothing happened because they couldn't do anything and then it's frustrating and it's a waste of time So let's look at at an example So let's say that we we made a timeline And then we took all the posted notes or the important ones from the from the timeline and put it into this diagram Because I noticed that there are some things that always come up Some things are directly in the do circle things that we can do something about like code review all made major changes That is something that the team can do something about if they're allowed to take the time But they can just cheat or lie to the manager Then there's some things that they can only influence like the communication with testers is bad That is not something necessarily that they can do something about but they can definitely influence it and here I am I know that we have like cross functional teams in agile and the testers are with the developers and the developers are testers But that's not always my reality And then there's this one in the soup change the location of the company and of course, I mean How can you how can you change the location of the company? And if this was something that they wanted to spend an hour discussing then it would be a waste of time So it's better to just be aware that this is something you can't do anything about But then for me the interesting thing is if you start working with these things if you're making course analysis if you're actually Discussing these posted note things instead of just accepting them as they are Perhaps there's something you can do perhaps Instead of just thinking about something you can only influence perhaps there is an action You can do perhaps you can move closer to the testers and now it's something that the team can actually do something about Instead of just trying to influence And even up here changing the location of the company is not something you could do But perhaps you could influence it by saying we could have a local hop somewhere if we were three people in this city Perhaps we could tell management that they would benefit from making a local hop here where we could work together instead of working in three different houses And that's what I meant with generating insights that instead of just accepting what it says on the posted notes try having a Discussion try figuring out is there anything you can do to make these things move into the do circle But also importantly to accept that there are some things in the soup that you cannot change and then Not not think about it anymore find out how to adapt to it And we skip that one again because we need the last and I only have six minutes left So, uh, Sarah here's other things the retrospectives are boring. They are a waste of time We should have a better facilitator. That's not something people say to her face, but she hears it like Somebody said it but the interesting thing is it's not just them It's also sarah sarah saying I would like to get something out of these retrospectives as well because she's a facilitator But she's also part of the team So this leads us to something that I call do it yourself retrospectives and uh, yeah Do it yourself can be difficult, right? But so the problem with the do it yourself retrospectives is that some say that the scrum master is responsible for the retrospectives Some people think that if you're the scrum master, you're always the one to facilitate the retrospectives Not necessarily a bad thing, but as I said you can end in this anti pattern And the anti pattern solution is let the scrum master facilitate every retrospective But the consequences is that the scrum master now station in this week and this week and this week And then we had a bunch of facilitators And then the facilitators would say well, I can facilitate this week or I can facilitate this week And of course some of the teams wanted the same facilitator all the time because they preferred that facilitator But some teams wanted a new facilitator every time because they were easily bored and they needed new activities Or perhaps there was somebody they didn't like but they didn't want to say it and then it's easier Just to say we want something somebody knew every time so we made this rotation and I tried it now only in two companies, but to me it works fine Other companies choose to have an external facilitator coming in and even sometimes the developers will be facilitators Some of them like to do that as well It doesn't necessarily have to be project leaders or team leaders who does it So these were the the six Anti patterns for retrospectives that I chose to Have and as a resume of the talk Um, I hope that being aware of these anti patterns will give you Better retrospectives more fun or as I said at least less painful And so I'd like to thank you for your time with this little cartoon. Thank you for your time Luckily, we have like one more minute And you talked about distributed retrospectives. Is there anything in particular you wanted to know about? Or is it just generic? Yeah Well, so I'll just I'll just talk and talk for three and a half minutes about distributed retrospectives So the problem with distributed retrospectives is that you cannot see the body language of people People don't know each other as much as they do if they're together and it's very difficult to see Um, if people are being quiet while they're being why they're being quiet So some of the things that I Demand to have is that I want to see everybody on video that can be difficult, of course If the wi-fi is bad But what normally happens if you put people down at a computer for an hour and they they are not on video If they mute themselves you might not hear it, but if they don't mute themselves you can hear the nice chatting sound on the keyboard or the email sound on the keyboard or even the click click click google search Or facebook sound on i'd become very good at hearing whether people are facebooking or chatting or writing emails While they have the retrospectives But if you have like their face if you can see the face of everybody then it's easier to spot if people are not there anymore It's not because they're evil It's because they don't think that this is important for me right now So when when people are zoning out, I'm not saying you should not be zoning out. You should not be doing email I'm saying is this discussion interesting for everybody or is this something that we should park right now And we should talk about that outside the retrospective Another thing that's difficult with the distributed retrospectives is I can't see like the The energy between people if people are together I can see those three huddling together over here So they're probably in agreement about something and somebody walking over there So they're not in agreement and then I can try to that is an interesting thing We need to discuss this because I can see you disagree. I can't see that when it's online And so there's a different things that are difficult But the width the video works and then I normally have a shared document where they're anonymous like a google doc Where everybody can write when nobody knows who's writing it can be fun But it also helps with the sugar coating that was mentioned in the beginning Because I've done some retrospectives with some people in cultures that are less polite than the Danish and the problem is definitely the sugar coating And what I've noticed is if it can be really anonymous when they put up things in the timeline Then people are more eager to try putting things that are painful up there And I still don't want them to blame other people but to point out things that are not good So yeah Anything else? Yes Yes So it starts up with the bank people come up with a lot of input, especially if the times are tough You know for corporations, we have had some decisions arguments It starts off well enough sustaining that becomes a real task because the board Keep drying up and the postage themselves don't come up. We also tried an anonymous, you know the google sheet Even there At times it seems like a verbal communication people in front would be much beneficial But when that starts drying up we go back to so there's a lot of who and for Is there any way to have a more sustained real time or sustained how to sustain both of you Well, I think I think the I think the answer to the question is generic and I know I have to So this will be the last story I think the answer is generic that again People think it's it's wonderful to start something new. There's a lot of positive energy But to sustain it they need to know that they get something out of it So I'll say again, perhaps you did that already But the point is to show them exactly this is what we get out of this because then they feel like they want to Do it and remind them perhaps every day at two o'clock There's a little ping on their computer saying was there anything you needed to put on the real-time board today I don't know if that's helpful But I think it's always that if people stop doing things is because they don't see the point Some some other things have got higher priority. They forget Yeah, I think that was it. Thank you