 Okay, we got five minutes show of hands. We're not starting. I know we've got two and a half minutes yet How many of you are doing Agile of some kind? Unqualified Agile almost wait, let me alright. Let's change that who is not Doing Agile anything Whoo, and they're on the front row that whether you're doing Agile or not How many of you are doing retrospectives? Well, why are you here? Ah Well, okay, that wasn't quite what I was looking for but that will do You want to learn? more About retrospectives, right? Isn't that what retrospectives are all about? Yes, maybe we should do a retrospective on the session when we get to the end. What do you think? Maybe Maybe we should do retrospectives on everything. Maybe even on your own lives How many do personal retrospectives? All right, cool All right, we saw people coming in and My goal is to get through the presentation part Early enough so that you feel you have the time to come up and look at the timeline It's amazing to me that most people don't do a timeline. I think it's one of the most powerful retrospective exercises there is and Sometimes it's that agile projects don't know how to do them So that's my goal is to finish early enough so that you have time to come up and read The cards on the floor and maybe add one of your own if you'd like I think we have a couple of chairs up here in front if we could talk people into putting things on the floor Well, all right, we just do the best we can if you don't mind sitting on the floor There are there's a little bit of space up here in front. I gave your chair away Are you all right with that? Okay Is it against code? I mean it would be in the US we could have people sit on the floor in the middle What do you Okay It's okay. You're bringing in some more chairs Okay, all right This is supposed to be a session about retrospectives and I already did a little survey to find out how many of you are Already doing agile development and what I got was almost everybody. So now that we have about twice as many people Let me do that again. How many are not? doing Agile not Yes, okay. All right. We wow we've got four or five Okay, you this really has a connection to agile, but retrospectives have no connection to agile You can do a retrospective on anything So if you're not doing agile development, you should be able to learn some retrospective techniques and talk about why You would want to do a retrospective In fact it has a long history and it has absolutely nothing originally to do with software So if you're not doing agile development, that's okay But my purpose is to say what retrospectives should look like if you are doing agile development So that's the point of the talk is to make that connection Wow, okay If you don't get a chance to ask your question or Talk to me about retrospectives. You've got my email address And I know that you'd have access to the slides. I've already sent the PDFs into the conference So you can download that it's unfortunate that you don't have a copy in front of you so that you can take notes But yes My experience is that most people who think they are experienced retrospectives People are not doing retrospectives. They are diluting themselves But remember that law of two feet if it starts looking like well, I already know all this then You can vote and that would be a good thing for the six Or eight or ten people who are standing behind and they would be happy to have you leave so Yeah, we shall see okay Alrighty, here's where it comes from for agile folks It's from the agile manifesto. Everyone knows the agile manifesto. Yes, right. Oh, yeah and these are one of the principles and It's one of the principles of the agile manifesto That so let's look at this at regular intervals That means frequently You reflect. Oh and What is that? What does reflect mean? Give me a synonym for reflect Yeah It's thinking it's thinking there's nothing here necessarily about looking back. It's thinking What a concept Often have to explain to managers who don't know some of what goes on in agile Development about pair programming and they say well Linda. What what is that? You've got two people Sitting in front of the same computer screen One of them is typing What's the other one doing and I say well the other one is thinking and The response at least in the United States is Thinking we don't have time for that We got to get this product out by June and in a way He's right That thinking does take time Retrospectives take time. It's an investment. It does not come for free So it says you got to do that Regularly you have to take time for thinking and the goal is That you're gonna think about how you're gonna be more effective and then Tune what's that Tuning any musicians tuning anybody play an instrument What does that mean tune? Yeah, there you have a standard a standard pitch that you have to make sure you are in tune with and Unless you haven't played that instrument in a long time. It's a small you have to if it's a guitar You have to make a small adjustment I used to play harp secured a long time ago, and if I didn't have a chance to practice sometimes that tuning was major But the implication here is that it is a small adjustment So the message from Kent Beck originally about what they meant Those white males who gathered to create the agile manifesto No women were invited. I hope I bear no grudge for that Not too much anyway Is that it was like driving a car? That's what Kent said When you're going down the road and I know that He's never driven in Bangalore or he might have chosen a different metaphor Because I think it's different here that while you're going down the road. You don't usually Move out of the lane like on that little three-wheel thing. I was in the other day. He just decided I'm tired of this lane I'm moving over the other lane and when we got over there We were facing a bus who was coming right toward us, and I thought oh god This is it. I know it. This is the end He was thinking about a more Regulated situation where you would stay in your lane and just make small Small adjustments Adjust tune So the idea is that you're going to stop Frequently and examine by thinking what are the things you can do? So that you can be better. Is there anything here? About dredging up Everything that went wrong Over the last iteration is there anything here. Do you see anything here about bad stuff? Or Problems or do you say anything? Anybody here who does retrospectives? Do you notice? That one of the things that can happen maybe in your boring retrospectives that you do Occasionally spend time on problems or what went wrong? Perhaps an inordinate amount of time Anybody yes, yes That's not the intent it happens I Facilitate retrospectives as part of what I do and I can see that teams who say they have doing retrospectives Immediately want to head down that road They want to immediately ask the question what went wrong in the last iteration or in the last release or Whatever the retrospective covers and that's not the intent so make a note of that please We used to do retrospectives back in the good old days. I worked on many many many large Projects I worked on the triple seven airplane. I worked for a lot of defense projects telecom weapons and We call them Postmortems Something about that word It's Latin. Do you know what the translation is? Yes post after Mortem after death Because in the medical profession Not always but in many cases after death. There is a post Mortem to examine a dead body So that's the image Something laid out on a slab Cold dead and No matter what you learn It sure can't help this guy It's too late and most of the time what you did learn from that postmortem Got lost It was documented And put somewhere and nobody ever looked at it again. Do you have that problem with your retrospective? That you create Something and then nobody ever looks at it again aha So now there's a switch in Agility we say we're not waiting Until the body is cold and dead We're gonna do something like a little checkup Just like you go in regularly to see your doctor and the doctor says you know I think maybe you need to lose a little weight You need to start exercising and it would be good if you would do those things While you're still alive So the information from a retrospective is designed to help you While you're living So that you can make some small adjustments and do a better job Just like you do for yourself So at the personal level because I'm advocating for personal retrospectives as well You should be looking at your own life periodically Examining how to be more effective at a personal level and then making some small adjustments while you're still alive and Younger than 71 so that you have time To do something about it So yes, it is a postmortem in a way, but I Sure like the name Retrospectives and that does not mean that you can't do a retrospectives at the end of the project In fact, you should You can do a retrospective at the end of each iteration You can do a retrospective when there are surprises you can do retrospectives when projects are canceled You can do retrospectives when there's a new customer It's not tied to end of iteration You just want to make sure that it's a common practice. It's a ritual and As humans we love rituals. It helps us get through bad things There is only one book on Retrospectives it was written by my good friend norm kerth Somebody in your company should have it you can share the copies and And here's what he says this is about learning that matches up with the agile manifesto You examine Your lie for your project and then you make some small adjustments and it's about learning Not fault finding So I mentioned that retrospectives are one of the things that I do as part of my consultancy. Why? Why would somebody either in another part of the United States or another part of the world? Give me a call or send me an email saying hey Linda Why don't you come on over here and do a retrospective for us? Why would they do that? Why would they bring somebody else in why don't they have me come all the way from Nashville, Tennessee To look at their project. Why would they do that? Well, they are thinking that's part of the problem I think here what kind of project would you suppose this would be when people call me up? Is it because wow we just had a huge tremendous success and we want to know why things went so well? No Yeah, it's more likely a disaster And When the guy who called me up? Takes me aside when I arrived there. This is usually a pretty high level guy who brought me in What is he looking for? He is looking for what went wrong more specifically What is he looking for? And Yes, and yes, and it is a he Every time every single time it has been a he he's looking for Who's to blame? Who is it? That I can say aha, let's get rid of him and then everyone else can feel Okay, so that's unfortunately the driver Behind a lot of retrospectives You know a few things went wrong so not only are you focused on the problem on The things that made you unhappy, but it's also whose fault was it? How many of you heard the stereotype? presentation the other day you start talking about them immediately Well, it couldn't have been our team. It must have been those Testers those members of other teams though business guys those marketing and sales guys those Executives who made the decision to keep this project going there must be somebody some they some them It's a very human thing So that is not an appropriate activity for retrospective Not only the focus on the problem but also the blaming in Fact we will look closely at the prime directive which specifies how you can even talk the vocabulary you use To talk about others So that you avoid that they that labeling I hate to have you down. I feel like you're Are you okay? Learning Not fault finding There is a book on agile retrospectives written by my good friends Esther Derby and Diana Larson and it builds on that other book So you really need the other one as a prerequisite and they tailor it by saying now that you're looking at Shorter iterations here are some suggestions for what the differences are But if you don't know what the original book was about then the differences really don't mean a whole lot to you And again at your team or your company should have at least one copy you can share it So we've got project retrospectives. We've got agile retrospectives and now Patrick Kuhl has come out with one. I think you can even download this and Patrick as someone I met at the retrospectives facilitators gathering there are a group of us who are professional Facilitators and we meet once a year at some part of the world and we share tips What have we learned over the past? Year about the projects that we've seen what works well in Facilitating retrospectives and so Patrick's kind of been a little Archaeologist and he has collected information about those meetings and here if you can get that And again, if you don't don't get it down send me some email and I'll tell you where that link is So you got three good Horses if you want to read more information about retrospectives I've written a lot of stuff about retrospectives so you can also go to my website and click on articles and underneath is a retrospectives I don't know is this work here. Do you know Winnie the Pooh? Really? Wow, okay, and Christopher Robin Yeah, okay, how cool is that who wouldn't thought he's got a different name in different countries No, he's called Winnie the Pooh Well, I like this quote Talks about Christopher Robin coming down the stairs carrying Edward Bear or Winnie the Pooh behind him So the quote is here's Edward Bear Coming down stairs now Bump bump bump bump bump on the back of his head behind Christopher Robin It is as far as he knows The only way of coming downstairs But sometimes he feels there is another way If only he could stop bumping for a moment and think of it Does that sound like any software projects, you know, there must be a better way But we have to have the time to stop bumping and think of it So it does require a moment for reflection It's not going to happen automatically In fact, we'll talk about that myth So here's why you do it. We have a myth That we believe that because we've had an experience How many of you were in the talk about the experiment with the managers where they ran a scenario and they made some Mistakes and then they did a little debrief and then they ran another scenario and they found that. Oh My goodness the managers made the same mistakes over again And when I told you about that were you thinking oh, well, that's those people Because we know we know because we're so smart and so logical that we learn Don't we? We learn From our experience. Yes Yes, of course. All right. How many of you have never made the same mistake twice So maybe oh you never have You've never made this You have made the same mistake. Oh, okay. Yeah, it's never made the same mistake. That's right Okay, I thought you were going to be an anomaly. I've never met anyone who's never made the same mistake Sorry, I was probably not speaking clearly Yeah, it's unfortunate That we have that tendency So I really like this quote from James Fallows. He says we want to believe that learning from experience is automatic That there's something about our brain that pays attention to what we've just been through And so that we learn from that But Unfortunately what we get from experience is a lot of well I sort of translated this so it fits software. It's like data and We know that now we're surrounded by a lot of data and That does not mean that we have any more knowledge That is it is not useful. We haven't really acquired that experience and translated it to something That's useful So data plenty of data But it takes work And that's really what goes on in a retrospective is an examination of the data and Then a conversion to something useful that the team can apply or use So that it becomes part of the knowledge of The team and the team members and then what you want to do is look to the future Because another problem we have both as individuals and teams is that we don't know What it is that we need to improve We need to have some focus If we're going to get better remember that's the ultimate goal is Becoming more effective if we're really going to do that you got to have some concrete Action plan that Says here's what we're going to do over the next iteration release project whatever it is or on your own life Here's what I'm going to do over the next week or the next month or the next year some Concrete set of actions that says here's How I'm going to be more effective So that's the purpose of the retrospective is the examination of the experience and then a determination of what it is and this should be very precise and Not too long a list in fact what we know about your brains and this is not just you you But this is you us as humans is we don't do well with more than three things So for those of you who are in that influence and thinking tutorial that I had on the first day We spent some time on that you can't handle more than three things That's another mistake. I see in a lot of teams is they get going in those retrospectives And they start looking at what happened and they lay out a huge list of things and then And I don't know whether this is boring or not, but nothing happens You don't look at it. You don't do anything with it. It's just a bunch of stuff that nobody pays any attention to So you have to limit the focus For that output that action plan from the retrospective or Nothing will happen. And if nothing happens then after a while people lose faith In the ritual I say it's just a waste of time We did it last iteration nothing happened the iteration before that nothing happened And it's either because too much time was spent on problems or winging Or an enormous amount of material came out that nobody cared about there was no ownership too much And so nothing happened. She's still here. So I suppose that's good There's another purpose for retrospectives, and I don't know whether this will fit your culture or not So I'll run it and we'll see what happens the very first time I did a retrospective It was at a telecom company where I was working and I was the patterns guru Wow back in the mid 90s And we had a little project that was Kind of innovative and new and everybody in the company was excited about it. It's called the ventures project and somehow along the way The ventures project got behind Now I don't know what happens in India But in the United States when projects get behind What do managers do Yeah, well, yes, they breathe fire as well, but they add some more people Anyone here know Brooks law Yes, somebody tell me what it is Yes, if you add people To a project that is late You will make the project later. Now. When was the mythical man month written? It's over 25 years old. It's had a silver anniversary edition You would think that by now we would have absorbed some of that information would you not Why do managers continue to do that? I? have sampled Manager responses on that so I can tell you what I have learned, but what do you think? Why do they do that? Well, yes, it's quick. It's quick and easy and Well, here are some things I have heard that if they don't Then their bosses will say did you add more people? Because their managers had not read the mythical man month either now here is the corollary to Brooks law if You add people to a late project you will make it later and if you add enough people You will bring that project to a screeching halt and It will never make any forward progress the end So this little ventures project started out with six Six people and they started to fall behind So one manager said we better add more people So they did and then another manager got a whole living civil I think we need to even add more people So that over the period of two weeks That team grew from six to 70 70 70 Over two weeks it ran for about two and a half years Cost the company ten million dollars and that's when a dollar was really worth something That project produced Nothing, how could that happen? So my boss came to me and he said Linda I would like you to go in there and see if there are some patterns Because we don't want to do this again talk to those those guys over there and see if you can figure that out I had no idea how to do that Luckily my friend norm kerth was writing a book about retrospectives and he was also a patterns guy and he said Linda here's what you do and he outlined for me some techniques for Running a retrospective and One of them was a timeline So I did I ran some of those little techniques and and that included a timeline. Well, what's a timeline? It's a a wall or a floor That's devoted to the collection of cards That are written anonymously by people on the project The timeline is a reflection of the time So in the beginning the cards are about say the first week or the first month or the first quarter followed by the next and the next and the next So the timeline is divided up and Then people on the team pick up a card and write About how they were feeling about something that happened and Depending upon how they were feeling they pick a different color if they were happy They wrote it on a blue card If they were surprised They wrote it on a yellow card challenged green red Yeah, mad angry frustrated Anonymous and with certain rules you can say anything you want and Then you put it on the floor or the wall and pretty soon what we have is a lot of little stories Stories about what happened at the beginning and then what happened and then what happened after that and and how people felt and I Thought well, this is a kind of a cool exercise will do this so in a huge huge section of the wall and we had some tape and and they came along and they wrote cards and They put them on the wall and I gave them a certain amount of time and I thought Well, they'll write the cards and then they will sit down and that's not what happened at all in Washington DC. There is a memorial For the Vietnam War. I don't know if you've ever been there. She has It's right in the middle of the city Vietnam was my war I guess My brother served most of my friends from college served So it it's the war I was most familiar with growing up and so they had a huge wall in Washington DC that was just simply the names of all the people who died in Vietnam It's just one name after another and It's in a very busy part of the city and Around it is the chaos and the noise of Washington DC, but as you go closer to the wall It gets very very quiet and you see people gathered in Small groups and they're standing in front of a particular part of the wall where there is a name Of somebody they knew and they'll stand and they'll they'll touch That name and they'll remember They'll have a little conversation among themselves That's what happened here. I thought it was one of the scariest things I have ever seen I am not a psychologist and I was totally unprepared That's exactly But these guys did now this project was canceled finally after two and a half years But I forgot to tell you that it was canceled right after Christmas What were those people doing over Christmas? How much were they working? How many hours a week do you think? Yeah, I usually is 60 to 80. Did they take time off for holidays? How long had it been since they'd had a vacation of any kind? Just like those Vietnam War veterans they stood in front of cards. They touch the card They stood and had little conversations. I Had the wisdom to get out of the way I just sat in the corner and I waited and after a while they did sit down And I thought maybe that was a good thing that if we hadn't done that If we hadn't had this chance to talk about it To get it out to write all those red cards So I was really happy to see this Research shows that when organizations go through changes and this was certainly a big upheaval People have feelings and thoughts, but no place to go We don't talk about that. We don't bring up In the normal course of business Those things that were bothering all the people on that project those 70 guys and What they were going through having given two and a half years of their lives for nothing and They knew it. So what happens? No place to go so their experience is carried forward as a heaviness a weight They take it with them To the next project and the next project no place To put it down So in a retrospective especially a Retrospective of a project like this is a time When people can talk about What they were feeling I have run retrospectives for companies Where I was walking the timeline and I saw a card that said My father died. I got a divorce My son had a serious accident is in the hospital Horrible horrible news that no one knew about They didn't talk about it and When everyone else on the team saw that card, which is anonymous by the way, they were very upset. Who is this? Well, maybe that doesn't happen in India Maybe you do talk about it, but if not It's called closure You need a way to reach closure especially on really Horrible experiences like This one this is not the timeline by the way, I'll tell you what this actually is But this is an example of a timeline so before going through that I would never have thought about it and maybe you haven't either This was in the period when I was still that really hard-nosed technical person Who was a designer and thought I could solve every problem by technical means and I didn't even understand What was going on here? But now that's how I run retrospectives around letting people have a chance to put that experience down It's liberating to write that red card and put it on the wall Most recently a project in Korea. I saw things there that were unbelievable Cards that came spilling out of people. I could hardly keep from crying Thought they've been having this as part of their Makeup for how long and now finally they get a chance to get it out Doesn't mean we're going to solve all these problems, but it is so liberating to just put the card on the wall That's definitely a part of retrospectives Yes, sir On the timeline yes, because a lot of people will not say things like that in front of others and And There's another reason for that too, and we'll come around to it, but this way you're there's also a sense of freedom Now I know in some organizations they might do hand-rating analysis But there are rules for what you can say so we do have to be careful But as long as we follow those rules you can say just about anything you want and if it were not anonymous You wouldn't have that freedom Yeah, so I think the anonymity is critical Yeah, so retrospectives came from the military and if you don't do retrospectives or if you need some justification There's a great article in Harvard Business Review That talks about how they do it in the military And in fact almost everything we have in organizations today comes from the military. Did you know that? Models for contemporary organizations are based on military a military structure. It's the oldest structure on the face of the earth Sorry Yes, it did everything came from the military Who is this guy? We also do it for any kind of safety critical fire fighters emergency operators they all have some form of the Sort of retrospective or postmortem here's a link to a sample for fire fighters And then I know you don't have time to read all the books out there, but this is a great one It's called the CEO in the monk Does that translate you know what a monk is? Yep, okay, so this is about a company that hired a monk and the reason why they hired the monk was they said We're getting ready to have a merger two big companies were coming together And one of the companies was sort of going to take over the other one So it was as though the other company was going to die So they had the idea of having a funeral and if you're going to really do it, right You need to have a monk so they did the monk came in and He had his robes on a Smoke And there was a big earn and people wrote little notes about the company And they put it in the earn and they burned all of the notes. It made people feel better It truly did They felt a sense of closure They could talk about the experiences with the old company How they were going to miss it It was definitely a good thing it worked so well that the CEO decided to keep the monk around You never know when you might need a monk. I think companies should have monks around just in case and For this particular company it turned out to be a very good thing. It's unfortunate This is a company that sat right across from the World Trade Center and on 9-11 People were standing in front of windows and watch as Two planes destroyed that building so as you could imagine The monk was very busy that day You never know it's important to Think about Ritual Why we're hardwired? We've been doing rituals of various kinds as long as we have been human We have funerals. We have ceremonies We we lost it I did a retrospective recently in Finland and their rituals around the sauna and the CEO said we're gonna start doing saunas We used to do them. It was a good thing So you have to find what works in your culture Bring in a sauna bring in a monk whatever works. So here are the rules. I have mentioned norm curse prime directive But here's what it says No matter what we learn No matter what comes up in the way of evidence on the timeline or in any of the other Exercise no matter what we learn. We are going to assume At least for the sake of the retrospective for that short duration We are gonna say to ourselves. I believe That everyone on the project was doing the best job he or she could Now of course we know more now We know that if we could do it over again We would probably do a better job Simply because of what we have learned in the interim, but at the time Given what we knew given our skills and abilities We were doing the best job we could and that applies to anyone that interacts with the team That has to be a basic assumption if you're gonna write a card about how you felt it cannot Call into question Anyone's contribution You can talk about Anything that happened any event for instance suppose you had some problems with the database And on your project suppose there was only one person Responsible for the database Do you suppose it makes any difference? Whether you say Well, we had a lot of problems with that database or If you say you know, I'm gonna call him Fred. I'm sorry. I hope there are no Fred's in the room Okay, you know Fred really screwed things up for us. I had no end of trouble Could it make a difference or do you mention someone's name? Because everyone knows That Fred was responsible. He was the database guy. Would it make any difference? Is this just Game-playing to say you can't say Fred you can talk about the problem, but you can't call into question Anyone's contribution and you can't lay blame You can praise Fred all you want, but you can't say Fred is an idiot How did we get stuck with this guy? Those are the rules and You can't do that for anybody else on the team or anybody you interact with You can't say those marketing people so you can talk about events or problems But you can't point your finger or mention by name Blaming Another person or another team Not allowed You can't write it on a card. You can't say it in an exercise. You can't put it on a flip-chart Whatever the exercises are you're doing in the retrospective not allowed. No blaming No naming Do you follow that? Very good That is the first requirement. In fact when you begin your retrospective that should be on the wall and If you forget at any time It's the job of the rest of the team to say remember we have all agreed to follow the prime directive That's usually enough to call people back From the blaming game and getting caught up in Who is responsible? For whatever the problem was so we know this takes time because we don't do a good job of remembering from experience and One of the problems we really have is that there's a myth We all subscribe to that yeah But you know if it was a really bad event like this project that ran for two and a half years We'll never forget it just like 9-11. We'll never forget it That's going to be emblazoned in our memories forever So there was a very famous experiment done after the challenger explosion. Was that something that you heard about? Yeah, okay, the challenger blew up and Everybody at the time says I'll never forget what I was doing when the challenger blew up. Yes Sorry It's not in here. That's not the job of the team to say you're responsible It's your manager's job I suppose and that the the question that would come up is does the manager come to the retrospective This is not about a performance review. That's something yet again That's very different if you're running performance reviews in the retrospective no wonder they're having problems What's the purpose of a retrospective? What's the purpose of a retrospective? Learning learning tuning adjusting becoming more effective. That's why you hold a retrospective It's not about accountability or blaming or saying what went wrong and whose fault is it? It's about how can this team? Be better You have other things in your companies. I'm sure about Evaluation and performance reviews and who's accountable for what and who's really doing their job and not but that's not what those on here Absolutely not. Yes, absolutely Yes, absolutely Absolutely What time is it? Okay. I'm gonna I'll just skip this I'll skip that Here are the questions you ask The first one is well, let's go back and look at all those things that really worked well for us That's that question most people ask the second question is what? The second question is not what are all the things that went wrong? So remember we talked at one time that said, you know, that's something that happens in retrospectives is that people get hung up on problems There's no opportunity here for that the question is not what went wrong We don't even ask that We want to know about everything that works really well that we don't want to forget and the second question is what should we do? differently There's a big difference Between the material that's elicited by what should we do differently and the question? What are the things that went wrong? Remember the goal of a retrospective is to improve be more effective It doesn't have anything to do with solving all your problems For one thing you can't solve all your problems. I'm sorry You often don't have the authority or control over many of the things that have caused your problems But there are always things that you can do differently so what really worked well focus on that What should you do differently? What did you learn? What still puzzles you? I'm going to start moving here Sometimes these are questions keep change Puzzles, so here's what should happen in an agile project Is it as you focus on each iteration? What worked well and What should we do differently? Those are all about small experiments and in fact in each iteration That's what you should do. No more than three In every iteration you should be performing a real experiment. What should we do differently? That is the experiment and when you do the retrospective and Ask those questions The questions are about the experiments and on the basis of the answers to those questions Then you decide what the next set of experiments will be and for agile projects That's the rhythm of retrospective iteration retrospective iteration iterations are about Experiments so in the last iteration we had say two experiments that we were going to try Now we're going to ask what worked well about those experiments What did we learn so that we can do something differently based on our experiments? So we had to comment earlier that nothing ever happens as a result of retrospectives What happens now is you're going to do an experiment That's what's going to happen and then when you do the next retrospective It's about looking at those Experiments and that's what it is. It's experiment Exap in fact That's the only way you can do a real experiment is to examine the outcome and the experiment should be something that you can measure and That you can quantify so that when you get to the end you can say yes The experiment worked, but we learned this so now we're going to try something else a small change so what you're doing is tuning and adjusting and and experimenting all the time and That's what you should do with your life At the end of every day at the end of every week. How did my last Experiment work well this worked pretty well, but I think I will do this differently in the next day week month year You see the difference So you're not starting from scratch You're not saying why well what worked well No, it's what worked well about those experiments that we decided to do in the last iteration What do we want to do differently this time tweak some of those experiments? Maybe try a new experiment and they should be little and you should never have more than three of them in an iteration We're supposed to be ending now. Aren't we? Yeah And and I wanted you to have a chance to come up and look at the timeline So I want to do that go one question. Yes for a two-week iteration 15 20 minutes and when you go into the retrospective you'll already have the timeline It's already done Because you're going to build it in real time You're going to start it on day one of your iteration and as things happen You're going to put cards on the wall and every day Everybody's going to read those cards and on your way to the retrospective You're going to walk through that timeline and say oh, yeah. Oh, yeah And in fact when you walk in the room, you've already got your ideas for the next Set of experiments it depends on the length of the sprint absolutely so if you're doing 30 days I would take a little bit longer But most people are doing two weeks and the teams that I coach get by with 15 to 20 minutes And it's just hey what works well with those experiments. What are we going to do the next time and? Most people walk in with ideas for experiments and it's our it's a done deal. They've been talking about it for two weeks I would ask the team for some teams they're okay with having managers or executives or The business people or outsiders from the team. They're fine with that others. No So it depends on it depends on the team Okay, I'm I'm sorry I'm I'm running up against my time limit and I want to make sure that you have if you've never seen a Timeline you should be doing it and on an agile project you build it in real time So if you can come on by thank you