 Good morning, good afternoon everybody no matter where you are on the globe today and welcome to The session this morning from I know on team meetings that don't suck Something which made me smile avoid retrospective anti patterns certainly something we all keen to learn about and we joined today by I know Cory From Denmark actually so true global conference today, and we're glad that you can join us today I know Hello everybody. I wish I was in India right now Not just because of the weather which I'm sure is nicer than the very cold Denmark But also because you have such cool earrings and very much forwards to go in there again and getting more earrings So today I'm going to talk about team meetings that don't suck with the help from retrospective anti patterns and The way that I learned about Retrospectives was I think 15 years ago at a conference with Linda rising she talked about retrospectives and she gave me this book Project retrospectives by norm kerth. So I read this book and I found it Fantastic, and if you don't have it you should you should try to get a hold of it. It's difficult, but you still can and That really encouraged me to start facilitating retrospectives Just with the team that I was working with at the Danish IT company But then I started facilitating retrospectives for our customers and now for the past Ten years. I've been an independent consultant and I'm actually mostly facilitating retrospectives Also had a chance to To give a course together with the last and who wrote the agile retrospectives in 2006 and this book is fantastic You're facilitating any retrospectives because it gives you a very good introduction to what you need to do How you should prepare and what you should be warrior And there of course the reason why I'm doing this talk is because I wrote this book called retrospective anti patterns Which shows all the things that I did wrong in my 15 years as a facilitator and what I did to Dremedy it. So if you want to learn from my experiences with the retrospectives, you could you could read this book so I'm going to go through six of the retrospectives from the book today and My goal with this talk, I'm always trying to tell people Why they should spend these 45 minutes because when you're on your deathbed and you're thinking I only have 45 minutes left If only I hadn't seen this talk with I know I would have more time So what's the reason why I'm spending time listening to this talk right now? It's because I want your developers to look like this when they hear this it's retrospective time So then they're not trying to run away. They're actually really happy that it's retrospective time. They're like, yay That's what we're going to do now. So that that's my aim To enable you to make retrospectives that that people really appreciate and do not feel is a waste of time But first I want to say what I mean by Anti-patterns and what I mean by retrospectives because some people Misunderstood these terms. So first off a pattern that you know is a literary description of experience So it has a pattern name, which is really important for discussing This solution then it has the context and forces the problem domain that you're in when you want to Apply this solution then you have an abstract pattern solution that can then be implemented in your particular context And that pattern solution has benefits and consequences now an anti-pattern to To look at this in contrast to a pattern it also has a name which is equally important to have the anti-pattern name to say Are we now talking we're in this situation? We want to avoid this situation. It also has a context and forces Then it has the anti-pattern solution, which is what you Accidentally do because you think it's a good idea, but it turns out that the negative consequences are larger than the benefits and Then in an anti-pattern, you don't just have the bad solution described You also have the refactored solution. So how can you get out of this situation or how can you avoid getting into this situation again? And of course the refactored solution has benefits and consequences as well. Nothing is without consequences So let me give you an example because the interesting thing is that over time and in a different context and with a different Technology something that is a pattern solution somewhere can become an anti-pattern solution somewhere else as an example The microservices architectural pattern is a pattern solution but in some contexts using the Microservices Architectural pattern can become an anti-pattern and suddenly your architecture can start looking like this Which is a mess of microservices, which is even worse than the monolith that you had in the beginning So the refactored solution in some of these cases is to say let's go back to the monolith Because actually the microservices did not apply well in this context. So you see you have the problem You have the anti-pattern solution and then you have the refactored solution If you look at patterns, then they actually the different patterns go through a gardener hype cycle like the Also like the microservices pattern it went through a peak of inflated expectations and everybody wanted to apply these microservices Now we're at the throw of this illusionment where a lot of people are Noticing we can't really implement these microservices well for us and it's actually worse than it was before and then at some point It will end into that plateau of productivity Where microservices as a pattern is used exactly in the right places where it should be used and not overused So that is sort of the life cycle of patterns and anti patterns and the anti patterns I'll go through today are things that I thought the anti pattern solutions I thought were was a good idea, but then it turned out they had negative consequences and then I refactored them So that's what I mean when I say anti patterns. What do I mean when I say retrospectives? Retrospectives is a recurring meeting for a team where they share what has happened They are appreciating what happened both the good things and the bad things and they appreciate each other as well and Foremost they're learning from this. So to me the retrospective is a recurring team meeting for the team by the team and It's the core of agile development It is the essence of inspecting and adapting because what you do at a retrospective is that you're inspecting You're looking at the situation we're at right now And then we're trying to adapt and change things make little experiments and overall to understand everything is to forgive everything so this Recurring retrospective meeting also gives you a chance to understand why things happen and then forgive other people instead of bearing a grudge and having Having scapegoats in your team saying he always does wrong. She's always stupid Then you have this chance to really understand what went wrong and to learn and to forgive So with those two concepts at hand, I want to go through the the six anti patterns that I've brought and If you want to ask questions while I'm talking you can use the chat or the Q&A I'll sort of try to look at it from time to time But there will be time at the end and Debbie will help us with the Q&A if there are any questions that I haven't answered during the talk Thank you Debbie So the first one I want to talk about is the wheel of fortune the wheel of fortune is one of the anti patterns that I see most often and For a wheel fortune you should as you see the little octopus that it's sort of turning wheel of fortune as you wouldn't typically and then sometimes The the arrow hits a price and sometimes the arrow hits something. That's not a price And that's the whole point of this anti pattern is that sometimes you're lucky and you're working on the right thing and sometimes you're not Let me take you through this Imagine that for the data gathering you're using these start stop continue posters. I I found a picture where they're in like a wheel of fortune But normally people just have these three posters start stop continue sometimes it's do more of sometimes It's also do less up and what I see often is Is that this is the retrospective? They say let's let's just brainstorm on things you should start stop and continue doing so sometimes what comes up is that we Should have more pair programming. We should have less meetings. We should stop ignoring the pull requests and The then because they want to rush through the retrospective They say great if we want more pair programming will just plan more pair programming three days a week three hours a day And these people we want less meetings white will only have two Stand-up meetings instead of five and we'll only have every other planning and every other retrospective So we cut down on the meetings very efficient and to stop ignoring the pull requests We'll make some sort of bots in our slack conversation so that people will never forget and cannot ignore it Right and then that retrospective is over and if the problem really is that people forget About pair programming and they forget about the pull requests and they actually have too many meetings Then those action points are relevant and great as a result of a retrospective But unfortunately what you see when you gather the data is sometimes just a symptoms of the problems and not the actual courses So for instance, if you have this more pair programming If you dive a little bit into the discussion about this Maybe you would see that the reason why people don't have pair programming is because they don't trust each other Maybe there's not psychological safety. Maybe they don't know what technology they should use to do it online Or maybe they just don't see the point Maybe nobody has ever explained to them how this in the long run is much more efficient than just working as a soul developer So planning to have more pair programming will not solve the underlying course and the same with the meetings I have so many retrospectives where people say we want less meetings. We have too many meetings Let's just cut down on the meetings and If the problem is not the amount of meetings But the quality of meetings and the thought behind the meetings then this won't help because even though you have less meetings They'll still be a waste of time. They'll still be frustrating So you just need to look at the quality of your meetings. Who should you invite? Is there an agenda by spending too much time? I'm I thinking about what the expected result is and what you want to use that result for could one big meeting with a lot of people I've actually become Like ten smaller meetings with less people that would be much more efficient and stop ignoring the pull requests Well, maybe there are other reasons for ignoring the pull requests Maybe people don't feel that they have enough knowledge or they have the skill set to actually do that so There can be many courses behind these things and just solving what you see in Gathering data could could be a waste of time because then you come up with action points that won't help you It's like putting skin lotion on on skin cancer It will perhaps remove the rash but the skin cancer is still there and then you will have retrospectives where The same problems pop up again because the course the underlying course is still there So The anti-pattern here is if you just want to rush through the retrospective and as you are gathering data You're already planning what to do what you should do instead the refacted solution is to go back to the basics of a retrospective and go through the five phases Setting the stage gathering data generating insights deciding what to do and Closing the retrospective Closing the retrospective so so set the stage get ready This is where you look at the action points from the last retrospective. You follow up on them Did we do it? They did have the expected effect or they did not have an effect You ask everybody to say something because when everybody has said something Then it's easier for them to say something during the retrospective. Maybe there's a theme for the retrospective Perhaps one of the things that we didn't have time to talk about at the last retrospective We want to focus on that now. Maybe the testing process Or could it could it be how you're learning as a team? So setting the stage is really important Also to make people feel that this is the room. We're now closing and everything that happens in here will stay in here Gathering data. This is the sometimes. I think the easiest part of a retrospective Because you can use the start stuff continue nothing wrong with doing that or the timeline or the ship retrospective Or there's so many other ways of gathering data in retrospectives that are more fun And I think it's important to shift the way you bear the data from time to time because the brain is a lazy lazy organ So if you constantly ask the same questions to the brain, you'll get the same answers. So try shifting that up a bit And then comes the interesting thing for this anti pattern the generating insights So generating insights is the part where you should be digging more into these action points And I see that there's a chat. It could be digging more in details could lead to pinpoint someone Maybe I misunderstood that question. I'll come back to that later. Maybe you're talking about creating a scapegoat So I'll I'll resurface that one later So generating insights with this anti pattern is to spend more time trying to understand why these things happen So it can just be to talk about the post-it notes. So what happened? How did we end here? It could be the five wires or the five house If you have something that is a recurring or a big problem that you think is very critical and you don't immediately see What is causing this or you think that it's so complex that there are more things causing it You could use this This fishbone diagram also calls the ishkinava diagram So what you do here is that you say, well, we have a problem and we put that problem at the head of the fish And then you draw this fish skeleton So the problem could could be we have a missed deadline. I know there's a spelling error there, but it should say deadline So we have a missed deadline and then we ask the people in the retrospective to brainstorm on okay, so how how could we What could what could have caused this to happen? What could the causes be and then people maybe say well, we missed the deadline because of a poor prioritization We we didn't prioritize and we didn't reprioritize when we learned something more Maybe we had too much tech debt and we had too much to struggle with it was too difficult to implement these solutions based on this technology We have could also be that there's no motivation There's no celebration of the small wins It could also be that the cry requirements were set too early And of course if you ask people to come up with these things in the brainstorm Everything is okay. So somebody might say well, it's because the desks are too small That might not be the real cause but they need it to say it and it's a good time to say it So again when you brainstorm then accept that it is a brainstorm and you get everything This can of course also be done asynchronously if it's an online retrospective You can send that out prior to the meeting and people have more time to think about it and to add on to other people's courses And the next point is deciding what to do and there's a lot to be said about deciding what to do. We could talk about how do we actually Decide what to talk about what do we how do we decide what to do in the action points? Is it a democratic vote? Should we use consensus or consent? We don't have time to go into this today But it's important to think about how you decide what to do based on what you did at the retrospective And then the last thing is closing the retrospective make a summary of it so that people don't afterwards walk out and say How did we go from here to there? Who decided these action points and what are we going to get out of them? Just remind people we talked about these things these problems and we celebrated these wins And then we decided these action points are these retrospectives And also when you close the retrospective, you should make sure That somebody's responsible by actually getting these action points or experiments done They don't have to do all of it themselves But somebody should be responsible for initiating it for sending the first email for setting up a meeting and for Feeding back into the next retrospective in the follow-up on what happened So you can see that the retrospective has these five phases and it fits well with the the life of any meeting The life of any meeting looks like this Where you start with a topic where you're in agreement And then you sort of you open the retrospective you talk about All these are my experiences. This is more data. This is what I've thought about So you you're in the divergence phase and then you're in the groan zone where people are discussing and And trying to figure out. Oh, is this good? Is this good? Maybe this works Maybe this doesn't work and then in the end you're you have to converge the retrospective or any meeting into something Where you have a decision you have some sort of conclusion in in a retrospective It will be one two three action points or experiments in other meetings. It might be We need a follow-up meeting or this is what we decided to do So in some teams you will You will see that that it's easy to go into the divergence But once they're in the groan zone, they want to stop and they want to jump into the convergence again Because if their developers they're trained to come up with solutions So whenever they see a problem They want to find a solution immediately And that's how as a facilitator you need to keep this groan zone open. That's what you do in the generating insights phase You're saying we're not talking about solutions right now If you have a proposal, please keep it in in mind put it down on a poster notes If it's an online retrospective, maybe you can have somewhere to put the proposals Outside of the viewpoint of other people So that people have a chance to get it out of their brain so they can work in the groan zone But we don't want to forget about it, but we don't want to jump to conclusions too early We want to spend this time Keeping this room open So I can see that there's somebody asking what are techniques to use in a team where most of the team are reluctant to provide Inputs and what we get as data points are appreciations, but the problems are never revealed Well, I I hear a lot of people asking about this. How do we actually make people say something that's not just positive things? And again, we can talk about our symptoms and causes because That the people won't talk about problems. That's the symptom And then we can think about the cause So one one cause could be that they are worried that if they say something which is negative, it will have consequences for them So one thing you could do there, the easy fix is to try to make it anonymous. Who's saying what I'm using often a google drawing And I know that there's a lot of the online things like retro and other things where you can use A ways to do it anonymously If you're doing it in real life, you can try to do it as anonymously as possible But it's difficult if people are writing on post-it notes So if you sense that's a big problem, maybe you should switch to an online one even if you can do it in real life Another thing that could cause this Is that they can't think of anything to say. They can't think of anything that is negative to say And what you could do here is that you can ask them to come up with things asynchronously before the retrospective Because maybe they need time to reflect. They can't think that fast and put things up or they've forgotten what happened in the last two weeks So collecting things asynchronously sometimes helps I've also seen people saying that you have to put three things that's good, three things that's bad and three things that you're worried about or you're wondering about Of course that can help as well, but it's not really solving the cause, it's solving the symptoms So they will come up with things or maybe just copy what other people did If the cause is that they are worried and there's no psychological safety, no trust That's something you could work with, but that would have to be also outside retrospective That's not something you can fix in the retrospective In a retrospective you can create a relation between people which is part of what trust is made of So you can start working on that, but if there's a huge problem with that, people don't want to share It's something that you need to address and work on also between the retrospectives to make it more safe to To be uncomfortable and to say uncomfortable things Another thing that I do sometimes if people don't come up with things is As I said before, if you ask the brain to come up with things with the same questions, it'll give you the same answers So sometimes I say, well, let's have a different kind of data gathering So sometimes instead of just having free form writing on posted notes, I use this team radar Where I have these spokes that says what's the quality of our code, what's the communication level like, what's the communication within the team With other team members, how happy are we working with this team? And then people put dots on these spokes and they don't have to come up with things and it's also anonymous And then you can see, okay, so on the happiness spoke, most people are happy, but there's a few people who are unhappy So we need to think about how we can make it better for people to work in this team or we have a problem with the tech debt or the testing, how can we work with that So find different ways of gathering data, maybe they're shy, maybe they're worried, maybe they don't like writing text, maybe they don't think that fast, they need reflection time So figure out what the problem is and try different solutions Maybe here is proposing set up working agreement in the beginning of the retro, yes, that's something that you can do, so maybe we cannot laugh at what other people say or other working agreements like that Yeah, so that was the will of fortune and I better move on a bit even though I want to answer questions because I want to go through a lot of things before I go back to the Q&A So the next one I want to talk about is in the soup and what you see here is the octopus trying to lift the weight that's too heavy for it and the octopus here is a team, it's a picture for the team because as you know an octopus has 60% of their brain in the tentacles and the rest in the head and in that case I think that an octopus is like a team where all the team members have their own intelligence but then they have a shared intelligence and they have to work together So sometimes people are discussing things in retrospectives that they can't do anything about and that can render it a waste of time because if they continue to discuss something that other people should do or that the management should do and they can't really do anything about it then of course it's a waste of time, they should just accept that this is something they can't change and then adapt to it So let's dive into this. If I noticed that a team does this over and over again, I introduced this soup exercise. You can also call it the circle of influence and it's not something that's native to retrospective results, it's used in other ways of talking about problems as well So after they've gathered data or when they have brainstormed for things to do, I say okay so let's put these things in this picture, the things that you as a team can do something about, let's put them in the middle, the things that you as a team can influence that put them in the outer circle and outside the circle are the things that you can't do anything about. This is both interesting to use after they've gathered data but also after they've brainstormed for proposals for solutions I want them to reflect on it and then I say well step back or look at it again, don't read the notes but look at what amount of posted notes are in the soup, maybe you're turning this into a regret perspective where you're just complaining about things that you can't change What you should do is focus on the things that you can change right now and then try to be constructive about that. So let me give you some examples and these examples are taking both from after gathering data but also deciding what to do so maybe you want to change the location of the company that's in the soup that's not something you can do anything about. Maybe the communication with the testers is bad. Well it's something you can influence but it's not something you can change yourself but co-review of all major changes that's something you can't do and the interesting thing with this is that well then you could just say well all the things that are in the do other things that we're going to talk about or things we're going to do something about but if you like with the generating insights if you try to go into these discussions then sometimes maybe you notice well there are things we could do as a team we could come up with reasons for a local hop that won't change the location of the company but maybe we can influence it and maybe we could move closer to the testers that's something perhaps we can do we can make the decision about and that might enhance the communication with the testers so I like to use this circles and soup activity from time to time and it's something that I do when I see that a team won't take responsibility or if I see that there's something that the team continues to discuss over and over again and they don't seem to be able to solve it so that's called in the soup. So prime directive ignorance and I think that goes towards one of the questions that I skipped in the beginning that if you go and generate insights and you figure out what happened don't you end up pinpointing somebody who was the culprit who was the scapegoat I think that was what the question meant and that's why I skipped it in the Wheel of Fortune. So prime directive ignorance is when you ignore the prime directive and the prime directive is what Norm Perth wrote when he started talking about project retrospectives and I'll let you read it while I take a sip of water. So when I started facilitating retrospectives. I wanted to talk about this prime directive when I was facilitating retrospectives but some people at retrospectives thought it was silly and hippy happy they said we can't truly believe that everybody did the best they could now when we know that he's an idiot and she's very lazy we can't really believe that also because I know that myself I'm also not always doing the best I can so how can I truly believe it for other people. So the anti pattern solution here is to just forget about this prime directive and just not think about it anymore. But the problem is that if you do that, then you might end up in a situation where people are trying to find scapegoats where people are trying to figure out and pinpoint who's folder this. And it is so important for retrospectives that you at least try to have this open mindset that you try to have this positive mindset. Also for yourself because as a facilitator it's a very difficult job to do. So if something goes wrong and retrospective or isn't as constructive as you'd hope it would be. Remember the prime directive holds for you as well you did the best you could given the energy you had that day and the skills you had at that point. It makes sense to tell them off because they're not doing it on purpose. What makes sense is to figure out how can we change the way that we operate in the system of people so that it doesn't happen again can we change something in the process can we change something in the communication so that it's easier to work without making errors. What you can do as a refactor solution is bring the prime directive to your retrospectives you can bring it on a whiteboard or a poster. If it's an online retrospective you can send it in an email. Sometimes I do it in the calendar invitation for the retrospective that I remind people about this. And sometimes instead of just putting the whole prime directive with the wording, I just do it in my own words. And remember we're not here to find faults in individuals we're here to to improve the thing that we have together the system or the team. And then sometimes you have to remind those that need it because sometimes they forget it after a while. It is difficult to truly believe that everybody did the best they could but I think it is beneficial to at least try to do that it also makes it so that people are less worried about entering the retrospectives because they're not expecting to try to figure out that you did something wrong that trying to figure out how you can work better in the future together with the other people. So that's a prime directive ignorance. The next one I want to talk about is the loud mouth. So we talk about different personalities in the retrospective, and the loud mouth is one of them that loud mouth is one that wants to talk all the time sometimes interrupts and when they start talking they can't shut up again they just continue to talk. And the problem with the loud mouth is that they sort of they take the floor for the whole team and nobody else gets a chance to say anything. And if you the anti pattern solution is just to allow the loud mouth to talk to allow them to speak because you think all they should also speak and I don't want to be the evil one who tells them to shut up. So the anti pattern solution is to actually do something about it. One thing you can do it avoid clean on discussions, because loud mouth thrive in clean on discussions, because that's when they can take the floor and speak and nobody else can listen. So if you avoid clean on discussions maybe if you have something online you can put them into smaller groups and let them talk in smaller rooms then they only contaminate a small amount of people. Other people can be heard as well also sometimes use think pair share like the one two four all in the liberating structures that first people have to think about things reflect on things and then they take talking pairs and then perhaps they can share with the rest of the group. Because also some people are reflective fingers they need to think before they speak and other people are active thinkers they can't think unless they speak. Loudmouth could have that problem. So it could also be beneficial to talk to the loudmouth one on one instead of singling them out at the retrospective and saying shut up. Talk to them afterwards and say well it's great all these things you have to say but perhaps, perhaps you can dial it down a bit because we also need to hear from other people. Loudmouth are not always aware that they are loudmouths sometimes they think that other people are loudmouths because they don't really have that reflection maybe you can help them with that reflection maybe you can have a sign that you can use at a retrospective to say that they should now be more quiet. Sometimes it can also be helpful to let them know that they can speak later because sometimes they are worried that they've got something really important to say but they were worried that maybe the conversation will move on that they won't have a chance. And you can just say that we'll have around Robin will ask everybody in the team what they think about this so don't worry you'll have a chance to say something and we can do that both online and on site. So that's the loudmouth and actually if you have people who are silent it's the same situation. Avoid the plenum discussions, talk to them offline figure out why they're silent and make them give them chance to think before they have to speak. The next one is called do it yourself. And that's because what I see often is that it's the same person who's always facilitating the retrospectives. You're part of the team for instance if you're the scrum master and you're always the one to facilitate retrospectives. Well, then the problem is that you will not get a retrospective yourself you're too focused on facilitating the retrospective. So you will not be able to be part of the team in the retrospective so you will fail. And it means that you can either choose to be a facilitator or you can choose to be a team member if we try to do both it won't end well you will not be looking at the timeline and the different agenda and the different personalities and the body language. Or you will not be able to take part of the discussions so what I encourage people to do is to try to rotate the role of the facilitator within the team. And if that's not possible, then perhaps rotate the role of the facilitator between the teams in the organization, meaning that you can say well we have all these teams that need retrospective facilitation and then we have this number of people who'd like to facilitate retrospectives. You can take turns in facilitating the retrospectives for other teams so that they can also be part of the team when there's a retrospective and you can see what we did at one of the companies that I worked with in Denmark here. Some of the teams wanted the same facilitator all the time some of the teams wanted a new facilitator from time to time it really depends on the culture of the team, what they want. And if you use this way of facilitating where inexperienced facilitators facilitate retrospectives I'll encourage you to use some of the online tools there are where people don't have to be experienced facilitators because these tools will take you through the process and will help you to do what a facilitator should do so let's do it yourself. The last one I want to talk about before we dive into the questions. I can see that there is a lot of questions and I appreciate that. It's disregard for preparation and that holds for online retrospectives so this anti pattern was written before COVID but of course it's still the same. The problem with online retrospectives is that you need to prepare a lot more and you need to be very cautious about the time and you don't have a chance to look at people's body language in the same way. What I do is that I send an email the day before with a link to the document they should use and say please make sure that you can access this so that we're not spending the first two or three minutes trying to figure out where's the link to that and how can you access that and do I need a password to that because you don't want to lose those really precious moments in your retrospective. Send an email 15 minutes before just to remind them in 15 minutes there's a retrospective go get coffee go get a bio break and make sure that you can access the document. And then insist on video for all. I know that some people have problems with the technology or the internet so that they can't be on video but at least you should try to make them be on video in the beginning perhaps just for the round intro as I said they could just be smiling wave and perhaps if the if the Wi-Fi doesn't allow it they can just have a picture shared in the in the video tool instead of just their initials at just a picture of their faces much better to talk to. And it's very important for a facilitator to know the body language and to be able to evaluate the body language and interpret the body language of the people who are and the retrospective. So that's why as a facilitator you can say please be on video and I really like you to be on video because it will make my life a whole lot easier to see who needs to answer quick ask a question who's very angry and who who sort of lost interest in everything. It's very important to be able to evaluate this as a facilitator but also for the other team members. So insist on video for all and it's the same with the symptoms and the courses so sometimes people don't want to be in video and they have a real good reason for it but otherwise sometimes it's just a symptom of something else like I'm taking the retrospective from the car or cafe. Then the fact that they are not on video as a symptom that they don't really respect this time with the team members. And make sure everybody's equal so even though it's tempting if some people can sit together that they should sit together physically and the others are remote. Try to make everybody equal if somebody's remote make everybody remote because then the commonality is is the lowest denominator for the communication and some people are not better equipped to communicate than others. There's nothing worse than being a small video at the top of a room and trying to shout to other people and get their attention while they're having nice cozy conversation. So make sure people are equal. And if there's only one person who has to be remote then you can use an avatar you can have somebody in the room playing their avatar writing the poster notes for them showing on the camera the things that we're looking at but that's only if it's one person if it's more than one. It becomes difficult and prepare a strict agenda and an alternative. Because, as I said before with the circles and soup sometimes you need to change the things that you prepared. Maybe you have to change from clean of discussion to smaller discussions or to something written because there's a loud mouth of their silent ones or people don't want to say anything. Maybe you want to use that soup exercise. So, so you have to plan this a bit more when it's online because you have to prepare these online documents. And don't record it. Just don't. Because we want what happens in the retrospective to stay in the retrospective so don't record it. We want people to feel safe and that they can trust the system and say what they want even the negative things. That's the disregard for preparation and I think that now when you facilitate retrospectives people will be really happy. And now with the with the final slide of 35% of my book. I would like to look at the questions and see, have you seen any questions Debbie that you think would be interesting to answer I haven't had a chance to look at them send that much. First one is, is it always an interesting one. It's a goodie, a goodie but not an oldie but a goodie. What are the techniques to use in a team where most of them are reluctant to provide inputs. And what we get as data points are appreciations but the problems are never revealed. Yeah, so I think I've sort of, I think I've sort of answered it throughout the talk but I can summarize that you have to think about what is the course behind this because the symptom you see is that people are not sharing. If the causes that they are worried they're shy there's not enough psychological safety then you can either anonymize it that's a quick fish fix on this so that people can say things without anybody else knowing who it is saying it. And you could of course also work with the psychological safety or the trust that's something that you have to work on it takes a bit time. I think there's somebody saying that maybe we can. We can say in the beginning of the retrospective we can evaluate the trust how, how relaxed do you feel about sharing things and if people don't want to share anything then you could either say well let's focus this retrospective on how to build the trust or you can say we can't really have the retrospective now nobody wants to share anything. But if the causes that they forget things and they don't. They don't remember what happened in the last two weeks then you can ask them a string currently or send them an email a day before and say, look in your calendar and think about things that happened incidents that happens. You can also say well, maybe you change the way that you collect the data maybe you change to a different way of data gathering or maybe you change it to a way where they're just voting for how they feel about the technical excellence and things like that instead of having to write. So, those are some things depending again on the course. It always depends. Fantastic answer thanks to that. I know. And lastly, before we finish the session today there's one on the question list which is again another really good one retrospectives are effective only when leadership looks at them. How do you get willful defaults in leadership to actually look at them. What I think this means is that retrospectives are only effective when leadership accepts them and thinks that the team should spend time on them that would be one interpretation of this question. And the answer then would be that I think that you should. Make retrospectives with the leadership team and let them try it out themselves instead of having them look at what the teams are doing at the retrospectives have have them taste the dog food and that's what I do in some organizations that instead of just having retrospectives for the developers I have retrospectives for for the leaders because then they can see themselves how effective it is. I don't want people from leadership necessarily to take part in retrospectives and look at what's happening in retrospectives I want retrospectives be to be for the teams to change the things that the teams can change. If leadership needs to change something based on what comes out of the retrospective I'll ask the team if I as a facilitator can take these proposals to the leadership and ask them if they want to change that. I think that's a brilliant answer and I think you're you're absolutely right it's about retrospectives. You know throughout the organization the matter what what in quotes level we're at should be a practice that's common throughout so that's fabulous. Thank you so much I know for sharing your experience. I know I hope thoroughly enjoyed it and I love your graphics those are going to remain in in my in my mind as as those prompts those empty patterns. Thanks I know.