 We may have to readjust how we're doing this. So this is improving and extending retrospective outcomes. So this is a beginner, is billed as a beginner session. So I'm going to be going over some things that many of you may already know about retrospectives. So do keep that in mind. I mean, that's what I'm going to do. How many here have only learned about retrospect, have either not learned about retrospectives before or only learned about them through scrum training? How many of you have done additional looking at retrospectives on your own besides that? Okay, that will help me a little bit. I might be able to move through some of this pretty quickly. That one? You're going to be, this is going to be fun. You're just going to be there doing that. Setting me up for the next thing. My name's Diana Larson and along with Esther Derby, I wrote the first book about using retrospectives for Agile. There actually was a book before us by a guy named Norm Kurth called Project Retrospectives, a handbook 14 reviews, or project reviews. His book came out, it was written in the late 90s when people were still on four and five year projects with multi hundreds of people or whatever. And so it was really intended as a way at the end of those projects to capture learning. So Esther and I noticed that there was some evidence of interest in retrospectives happening more frequently. And so in his retrospectives, the way he describes the retrospectives in his book, they're three days long. So we sort of knew that wasn't going to work in a two week sprint. So we said, how do these things need to be rejiggered so that it is useful on a more frequent cadence? So that's why we wrote the Agile retrospectives book. For a long time, it was the only book. It's not anymore. There are a couple of two or three other books and some other resources that I'm going to point you to when we get to the end. Pat Cua has written a book that's actually not so much about the designing like this session is gonna be or that our book is about. It's not so much about designing retrospectives or that, but more about the role of the facilitator. So if you're interested in improving your retrospective facilitation skills, you might want to look at Pat Cua's book, The Retrospective Handbook. Ben Linder and Louis Goncalves have written a book called Getting Value Out of Retrospectives and they have a number of activities, some of which are sort of like you do one long activity as your retrospective, not all of them in that way. So now there are some other resources out there and I'll point you to some more at the end. The other books I've written are a book called Lift Off with a co-author Ainslie Niece. It's about getting teams started well. It's been out just for a couple of years and we are now working, we've learned some things since it's been out, so we're now working on a second edition. So that won't be out till next year, so. No, thank you. Is that for me? Or is that for somebody else? I don't think that was meant for me. Maybe Pradeepa ordered that. And so that's this book here, Lift Off. This book is, we're gonna talk about a little bit today, the Quick Start Guide to Five Rules of Accelerated Learning. It's a Lean Pub book, you can get it on Lean Pub. See more about that later and then of course the Path Through Agile Fluency article that you've already heard about this week. If you were here on Wednesday. So those are some of the models that I've been putting out there in the world and moving along. So how we need to get started, we are going to be focused on doing some real work in here, to the extent that we can. In order to do that, I think we are going to, looks like we're gonna need to, I thought four or five was my estimate, I think we're gonna need six people to a table. So if you can figure out how to get six people at a table, that would be good. Let's take a minute or so to do that. What tables still need a person? Okay, so there's some tables over here that need people. Yeah, let's make at least six people at a table. Seven will be okay. So then we've got, as this little bag comes around, please take out two cubes for your table. These aren't gifts, I will want them back later. But make sure that every table group gets at least two cubes, all right? And just pick them at random, it doesn't really matter. Let's get everybody. So just while that's going on, what's coming around is I'm asking you to take two of these cubes that are called Rory's Story Cubes. I was first introduced to this at an agile coach camp a little while, couple of, I don't know, year, two ago, pardon me, I don't know when it was. I can't keep track. And they come in several different additions. This is the sort of original. And I've been finding all kinds of ways that these are useful in various kinds of team meetings. So you might, this is a resource you might want to check up into. So do we have all our table groups? How many do we have? Yeah, any table doesn't have two cubes? Okay, can we get you a chair? Are there chairs coming? There they are, yeah. It's like being in a forest. There are all these Rory's Story Cubes. I'll put up up here. This is the original one. We also have ones that are more about actions and ones that are about voyages. And then there's some little supplemental ones about other stuff that you can get. They all work the same. They're just adding in some variety. Okay, that looks like we're slowly but surely getting settled. All right, so at your table, getting started, go around the table and say one word to describe what you hope to get out of this workshop, what you're expecting out of this workshop. Then go around again and pick up one of the cubes. Either one doesn't matter. Roll it. And whatever is face up, tell how that relates to your experience of this conference so far. And then in a third round, say what action you're gonna take to make this workshop valuable for you. Okay, so let's just take a few minutes to do that. Cut six people. Let's see if we can do that in 12 minutes. Okay, so you really have to move quite quickly. Just say your one word, move on. I'm gonna say important. Doesn't matter. Whatever your word. Sometimes it takes a little interpretation of the picture on the cube. Yeah, what's the picture on the top of the cube? How does that relate to your conference experience so far? Have to think a little metaphorically here. Yeah. When you're finished with the three rounds, somebody at your table, hold up your hand. Okay, okay, so you. It's, pardon, IT Agile. Yeah, IT Agile built that. I think the app is called Timetimer. And then finish up. This group is going to move more quickly. That's good. Part of the reason, I said that Esther and I started writing our book, and part of the reason was there was this, the 12th principle, the very last principle on the second age of the Agile manifesto says at regular intervals, the team reflects on how to become more effective than tunes and adjusts its behaviors accordingly. So more effective. Unfortunately, at that point in, I guess when we started was about 2003, 2004, we started working on the book, none of the major, well, I don't know if that's true or not either, but only one of the methodologies had any kind of practice that spoke to this. And that was crystal. That's Alistair Coburn's crystal, and he had what he called reflection sessions. But they still really weren't quite what we would consider to be retrospectives today. At some level, extreme programming thought that just by having a daily standup meeting, that was enough reflecting, tuning, and adjusting to do the job. And then at first, Scrum didn't have retrospectives, and then it decided to incorporate them as time went on. So that's why we wrote the book. There was this principle that said you should do this, but then there were no instructions about, stop, okay, let's go away. There were no instructions about how to do it. So that's why Esther and I started talking about it and giving presentations at conferences and ultimately published the book. So what we're talking about here is continuous improvement. This is the actual definition from the ASQ, the American Society for Quality. I doubt that it's very different at the International Society for Quality. An ongoing effort to improve product services or processes seeking incremental improvement over time, which in the lean world we call Kaizen, or breakthrough improvement all at once, which we also, we call Kaikaku, right? The transformational kind of shifts, right? Both are considered continuous improvement. But beyond that, if you've noticed at this conference, there's been a huge emphasis on the role of learning. Jeff talked about it, a number of the breakout sessions have talked about it. Ahmed was talking about it. Last night, I mean, it's come up over and over again. For those of you that this is your first day here, check with your table mates. It's been the topic of conversation for a couple of days now. And so continuous learning is an ongoing learning process that seeks to incorporate the lessons learned from the results of already implemented changes and I added in experiments into a continuous improvement program. So continuous learning is what enables continuous improvement. So that's reflect, tune and adjust, continuous learning. So we're gonna be focused on that quite a bit. A retrospective is a gathering, a get together, a focused examination in the present during which we look at what just happened to us, our immediate past experience in order to have some impact on the future. If you notice, this definition sounds a lot like the definition of feedback, right? Tell somebody now about some behavior they did hoping to have some impact on the future. Retrospectives are a way of the team giving feedback to itself. It is an introspective process. We can hold retrospectives at a number of different times, certainly iterations and sprints for sure. In the early days, those were called heartbeat retrospectives because they were an indicator of the health of the team. Is the heartbeat regular or something going wrong? Release retrospectives, end of project retrospectives like Norm Kurth wrote about. In the retrospective facilitator community, we've also identified this idea of surprise retrospectives. Retrospectives you do in response to some kind of unexpected occurrence in your context or your environment. It occurred to me today that there actually is now a new kind of retrospective emerging coming out of the community that's doing mob programming where they are having daily retrospectives. That's not even on my list yet, so why? Why do we do these retrospectives? Well, a number of years ago, we were asking in the, there's a whole community, international community of retrospective facilitators. I will tell you how to get in touch with that group toward the end here. But we began to ask ourselves, well, so how do we describe why some company would want to support holding retrospectives? I mean, after all, it's an expenditure of time and energy and effort that somebody's paying for and how do we know if we're getting values? So there were some internal retrospective facilitators and some very large companies who are a part of our community, Siemens, Intel, Nokia, and some others, and so we asked them, why do your bosses support you doing this with themes? And so they went away and they asked their bosses because they couldn't answer the question right away. And so then the next time, the next year when we got together, they said, here's what we've discovered. When we, while we cannot tie a direct correlation, there's nobody's done that research. What we have noticed and what our managers and bosses have noticed is that when we are doing retrospectives, team productivity increases, team member capabilities improve because of transfer of knowledge, product quality improves, team capacity grows, and team morale and collaboration skills get better. All of those seem to be good things that an organization would want to invest in. So that's, those are why we do retrospectives because we get a benefit. We get a benefit from this time if it is time well spent. The sad part is I get a lot of questions and I visit a lot of teams and, you know, sort of like what happened with the keynote. The, what I find is people are not holding retrospectives to get the benefit. They are holding retrospectives to check off the box on the list of things you're supposed to do in order to be doing agile. And so nobody's really paying attention to is the time that we are spending in this meeting every sprint really giving us a good return. Are we, are we getting any of these benefits? And if we're not, why are we spending time in these meetings? I mean, I, I am never a person who will advocate holding a meeting for the sake of holding a meeting or for the sake of checking off a box. So what we need to do is make sure that if we're bringing the team together to spend that time that it is time worthwhile that there is a return that we are building a benefit by doing this. So that's what I'm here to talk with you about today. The work of a retrospective is a little different from a lot of the other kind of work that we do. Mostly because it is very team focused. I, I am supremely confident that there is not one individual person in this room who doesn't know how to manage their own learning, analyze a situation and make some decision about how they wanna move forward individually. Unfortunately, in a lot of situations, we don't have as much experience or practice or just training support for doing that as a group. You know, when we form a team, even before it becomes a self organizing team, it has a life of its own. Just like a couple in a, in a marriage or in a relationship has that relationship is a third thing besides the couple, right? When we have a team that is trying to accomplish something together, it is its own thing. It is its own entity, its own party. It does, it needs its own care and tending. Just like we have to take care of our own health and our own bodies, we have to take care of the health of the team. And that's a hard shift for a lot of people to make. It's a hard shift for managers to make who have been used to doing, you know, one-on-ones and individual improvement plans and things like that. It can be hard for somebody moving into a scrum master role to really get that there's a difference between taking care of all the team members and taking care of the team as a whole. And a retrospective is a thing we do for the team as a whole. So it is about learning, thinking and moving and deciding and moving into action together as a group. And so that's why it's important that we take care in how we design these meetings, how we think about how they're going to run, how we set them up in such a way that we are facilitating that group action. There's one more thing I wanted to say here, but I have just forgotten what it is, so I'm gonna move on. So there are other folks who are looking at similar things. Lean Startup has the build, measure, learn cycle and that's about us learning as a company. It's not about just the individual founder learning something. It's about the whole startup group learning something. It's very similar. Dave was talking this morning about Kenevan and how we think about make sense, do the sense making of what's going on in whole groups. It's also a very similar thing, particularly if we think of self-organizing teams, as he mentioned this morning, as living primarily in this complexity space, getting really good at that idea of probe sense and respond in our teams becomes critical. There's another group that is also looking at complex adaptive systems and the way they function in the world and that's called the Human Systems Dynamics Institute. They are looking at the intersection between the complexity sciences and the social sciences and sociology and seeing how those things jointly apply. Some of those ideas jointly apply. So it's a little different approach than what the cognitive edge and Dave Snowden's folks are taking but it's all adding to the body of knowledge that we have. And one of the things that they've come up with is this idea called adaptive action, which is we take the time to sort of assess our situation, see what's going on, probe, right? Make sense of it, the so what part of this, what meaning do we, can we gain from what we see in our context? And then now what, moving into action, so responding. So build, measure, learn is action, thinking about it, learn from it, go move on to the next thing. There's a lot of consistency in these models that are telling us how we can be effective as complex adaptive systems. And retrospectives is another tool in that toolbox. So in Esther's and my book, we propose a flexible, scalable framework for agile retrospectives, for designing the retrospective. Now we're not gonna talk so much today about facilitating a retrospective. I'm going to ask on you to find a way to practice those skills and figure that out. It's really two different pieces, right? Getting good at designing the retrospective, understanding what we're gonna need, what's gonna need to happen in the meeting and then actually being in the meeting with folks and making that happen. Because that second part is really hard to do in a group this big, in a timeframe as short as we have, we're gonna focus on the design piece. And the design piece follows this model. Set the stage, gather data, generate insights, decide what to do and close the retrospective. Now when you think about gather data, what else does that remind you of that we were just talking about? Probe, right? Probe, what's going on here? We're gathering data. Or the what, what is this current situation? Or the build, right? Yeah, the OODA, does any of you familiar with the OODA cycle too? Observe, orient, describe and act, I think. It's very similar. So many great minds have come to the sort of the same conclusion. When you look at the Toyota, what is it, A3 or A4 process? A3, it's also very similar. I don't know why I can't keep track of those numbers. I think they need a better name. It's the size of the sheet, right? So gather data, generate insights, decide what to do and then close the retrospective. Now what you'll notice is the three parts of this that are in the circle are the parts that we keep seeing over and over again. But they aren't sufficient when we're bringing together people into a meeting situation because we understand we need some good facilitation skills there. And very often a retrospective happens on a day when there are a lot of meetings. There's already been the product review or the product demo and then maybe there's the retrospective or maybe there's some other grooming meeting that happens there. And then later on there may be the planning meeting or maybe the next day is the print planning meeting. So it's in a series of meetings. And so a good facilitator understands that you need to mark off the different kinds of work. Some people say you should never mix ceremonies, right? It's a very similar concept. So we set the stage and we closed the retrospective to really denote that this is a different piece of work than the product demo or planning or backlog grooming or any of those other things. Doesn't mean it's better. It's not necessarily more worthwhile. It just is its own thing and we need to consider it as such. So that's why the set the stage and the close the retrospective were there. So that just kind of a quick gallop through sort of all the high level things you need to know about retrospective. I do want to introduce another model. I told you about the book about the quick start guide. The quick start guide describes five simple rules for setting conditions for team learning. Actually it also sets conditions for individual learning but when we think of the team as an entity we can think about this. And the five simple rules in the quick start guide are keep it alive. And this one is the acknowledgement that there are humans involved here. It's how many of you are familiar with Christopher Alexander? And he's seen a few of you. Wow, there's a whole rich vein of things for you to explore. He talks about the quality without a name that is what makes us human. And that we need to be sensitive to that in our built environments and in our social environments and so on. So keep it alive is are we taking care of the human needs of people when we are holding our retrospective meeting? To apply it in a specific instance. For instance in this room it's getting kind of hot. If I had the power I would figure out how to cool this down. I mean I know that happened because there are a lot of people in this room and one of the things we do is generate heat. But so thank you. So we do what we can to make it more comfortable for the humans so we can do work and we don't have a lot of other distractions. I ask you to sit in groups of six at your table rather than trying to do all the activities in this session as one big group. Because I know you'll get more richness out of that interaction with just a few people rather than trying to interact with the whole group. Right? So there's some ways. If I just didn't have enough room in my suitcase to bring the numerous colors of sticky notes and other ways that I try to enliven the environment. The folks who were in the workshop, the Agile Fluency Workshop on Monday got to play with some pipe, colorful pipe cleaners and they were building things and it was really wonderful and I didn't have quite enough to get to this class. But so all of those kinds of things that we think about are people fed and rested and ready. I mean the fact that we have coffee when we need it and water available and all of those things help us be ready to do the work. So we pay attention to that. That's part of setting the conditions for learning. The next thing for setting conditions for learning is what we call do it for real. Our next simple rule is do it for real. Get as close to the actual situation of the thing you are trying to learn as you possibly can. So I formed you into teams. And as we go through this session, you're going to be doing some work in teams because that's how retrospectives are done. So we look for those opportunities. How can we get closer and closer? No matter what kind of skill we're trying to learn. How do we get as close to doing it for real? Pilots have flight simulators that are scarily real. They can't actually do that. Astronauts get dumped into pools of water so that it's as close to a weightless environment for them as you can get. So sometimes you can't do it actually for real but you get as close to that as you can. Setting first is about paying attention to the physical surroundings. Do we have what we need? Making sure everybody has a chair. Like we just did, right? Making sure that there's room for everybody. Looking around, taking care of that this setting is going to help us with the other four rules as we move forward learning. The fourth one is start obvious, stay obvious and that is we want to remove any hesitation or ambiguity or confusion about what we're doing to every extent possible because any of that stuff gets in the way of people learning. So in a moment when I'm talking about setting the stage I'm going to recommend to you that for every retrospective you have a focus. It's not just always continuous improvement or continuous learning. It's this retrospective we're going to think about our customers and our relationship with them. This retrospective we're gonna think about have we been following our agreements about what engineering practices we're going to use and which ones we're not? Are we having, are we all showing up on time for our meeting? What is the focus? How, what is the behavioral focus or the quality focus that we're gonna have for this retrospective? Because we need to make that very obvious and very clear. And then the last one is focus on flow. And that is the process, making sure that the process flow, the design flows. One group process activity builds on the next or sets the conditions so that the next one can happen. There's that we are looking at things not in big kind of overwhelming chunks but in the bite-sized pieces that we can take things on and then work iteratively. I mean, how much does that sound like working story by story, right? I mean, there's a lot of this that shows up in other parts of Agile. So the five simple rules, if you wanna learn more about this, there's a book on Lean Pub that you can get. It's pretty cheap. But I want you to keep these in mind as we move forward to talk about the rest of the things that we're gonna do for retrospectives. Cause these are really critical as well. So I guess we have design teams of six people. I want you to just take a few minutes, maybe three to five. See if you can get it done in three, that'd be great. And pick somebody at your table that has a situation coming up, the next situation coming up, where they really are gonna have to either participate in or lead or do something around a retrospective. And then that will be the focus of your work through the rest of this session. Okay? So have some conversation, figure that out. And then we'll follow the steps toward designing a retrospective. Okay, right, so somebody gets to walk away with their retrospective already designed. The other tables. What groups don't fusion and hesitation and ambiguity? That was bad. So for now you're just doing, picking who's retrospective you're going to design. And then stop talking. If you can hear me raise your hand and stop talking. Okay, there is the part about the stop talking after you've raised your hand. I noticed some people struggle with. A lot of hands will go up and they'll keep talking. Okay, so the follow the steps. We're going to do the steps now. Okay? So the first step is preparing for the retrospective. What I wanna make sure is that everybody has something to take notes on as we go through this with that team in mind that is gonna get your retrospective design at the end of this session. You'll be taking notes as we go through this. What? Stop that. Oh, that was that one, right? Got bells going off all over the place. So the first thing is to think about are there complexity factors? Was this sort of a plain vanilla sprint? Or was there some kind of controversy? Or was there a special conflict that went on where there are more than usual numbers of people involved? Did it last longer for some, maybe the team took on some additional issues that added complexity to the sprint? For every piece of complexity that has been added, you need to think about spending a little more time on the retrospective. Okay? So number of people, length of time, in terms of like releases, a two week release retrospective would look very different than a six month release retrospective, right? So you have to think about what are those complicating factors? Increased time, more people, conflict, controversy, unexpected occurrences, any of those things is gonna trigger you to need to spend more time in the retrospective than you might otherwise. So given that, given what you're doing, who are the people who you will invite to the retrospective? Is it just for the team? If it's a release retrospective, there may be some other, they're the release manager, if you've got those kind of folks or other folks might need to be a part of it. If it's an end of project, there might be, you might have customers, there might be even a group. Depending on the focus that you've chosen, you might invite different people in. You know, maybe the team has been struggling with some data management issues and what they're trying to build and that hasn't been able to be clarified and so that's gonna be the focus of your retrospective. You may wanna bring in some of the database folks to talk about how those interactions have been going. Who will you invite? How long do you think this retrospective needs to be? Now I have some sort of personal guidelines that I use. What I notice is that a group of five to seven people has a very difficult time getting to substantive improvement actions or experiments in less than 75 minutes. So that's sort of my bottom number. So for a one week sprint or a two week sprint, I would say 75 minutes for the retrospective. If the time starts getting longer than one or two weeks, if you've got more than five to seven people, then you need to look at a longer period of time. So keep that in mind as you are designing your retrospective. Location, are you gonna hold, if it was a plain vanilla iteration, are you just gonna hold the retrospective in the team room or if there was something touchy or had conflict associated with it, maybe you wanna get out of the team room, go to some sort of neutral new location where people won't be triggered by the same old stuff and be able to sort of start fresh in their discussion. That might be a conference room. That might be going completely offsite somewhere. The cafeteria. The cafeteria, yeah. So there are lots of choices you might have about where you're gonna hold this retrospective and reasons why you would choose one place over the other. And then finally, I am not a fan of the mandatory retrospective. On the other hand, you want everybody there, right? So the idea is how do we make it inviting enough? How do we create the conditions that say this is an invitation to come together with your teammates and find a way to make our work lives better or make our product better? Yeah, do you have a comment? Provide, keep it alive, right? People love to show up for food. I mean, it's a major part of being human, right? We like that. I have actually been in retrospectives where part of the retrospectives was cooking for each other or building each other's lunches out of food that was brought in, right? That is very powerful, it has that sort of breaking bread together kind of idea, right? And then finally, the focus. What's gonna be the focus of your retrospective? Is it gonna focus on engineering and teamwork or process or relationships outside the team or what is gonna be the focus? You want the focus to be narrow enough so that you can keep it obvious, but not so narrow that you're precluding real innovative thinking. So there's kind of a sweet spot in there that you figure out where that is. So it needs to be, it can't just be some kind of global focus. We're just going to make the world better. It's really hard to work on. But, yeah, but our team room, our bullpen isn't really serving us very well. How can we make our setup better? Would be an ideal focus, right? Yeah, you will comment? Before, if there's something really boiling under the surface, it comes out anyway. Generally speaking, if I come in from the outside, I will ask with a Scrum Master and team members what's been going on lately, I will suggest, does this seem like it would be a good focus? Scrum Masters, because they tend to have that more umbrella view, are often, especially when a team is new, are often good folks to figure out what that focus should be, or coaches might be good to figure out what that, after a while though, that needs to transition to the team suggesting what our focus needs. Someone, some team member says, I think this week our retrospectives should focus on this. But that is a maturity thing. That comes from doing a lot of retrospectives and sort of getting that sense of what's the right size, the bite size piece that we can tackle during a retrospective, okay? Okay, so that's getting ready. So you'll need to think about those things. Then you'll design using the Agile Retrospectives Framework. I'm gonna go through that in a minute. You would gather together your materials. We're not gonna really focus on that so much, but do you need sticky notes? Do you need wall space? Are you gonna be in front of a white board? What's all those kind of materials and equipment things you need? You're gonna need to have story cubes for some activity you're going to do, whatever. And you have to make sure you have, whatever activities you've chosen, you need to feel comfortable that you have the facilitation skills to work with that particular process. So sometimes that means practicing ahead of time, if you're trying something new. Sometimes if it's a really touchy thing, maybe you wanna rely on the things that you feel most comfortable with, right? So what we're gonna do is the design, we're not gonna focus so much on the materials or the facilitation. So set the stage. Here are some things that some folks do to set the stage. You have other ideas, right? You are not limited to these things that I'm gonna just show you very quickly here. Setting the stage is doing things like exhibiting the Prime Directive. If people hesitate to come to your retrospective because they think it's just gonna be a big blame fest, you might wanna start with the Prime Directive and have a conversation about safety, right? This is another way of sort of setting that tone and setting that context. It's an activity called Focus On, Focus Off. This one is in the book where you say, you know, we are here, at least for the first part of this retrospective, we're gonna be more in dialogue than advocacy, or more in inquiry than advocacy, more in dialogue than debate, more in conversation than argument, more in understanding than defending. Can everyone agree to do that? Here's another activity where somebody didn't ask people to say things so much as draw a face at the beginning of the retrospective on a round sticky note and put it up next to there and then just say one word about what that face represented for them, right? How they were feeling in the moment. As you'll see later, they then were able to come back to this in closing the retrospective and say, and how do you feel now? So anything's like that. For setting the stage, what you wanna do is get people into the room and focused on the work that's gonna be happening there. You want to give them enough information. Usually this is when you wanna show what your agenda is, so people know how you're gonna use their time and they can sort of let go and relax around that. Is this gonna be a big waste of my time? Oh, hey, no, she's got a plan, right? So that sort of thing, this is when you really re-emphasize the focus. You've probably told people about the focus and the invitation, but now you emphasize it again. If it seems like it's a situation where people won't feel safe, you might wanna spend more time in setting the stage, getting people to feel safe. Generally speaking, when teams get used to doing retrospectives, this goes pretty fast. You spend only a small portion of your overall retrospective time here. You might need to spend more in the beginning. Pardon? Yeah, right, right. Distributed teams, yeah. Okay, so I'm gonna bite-size pieces, stay obvious, start obvious, stay obvious. We're gonna focus primarily on co-located teams right here because distributed teams is advanced topics, basically. And in general, what I will say is what Alistair Coburn always said was the richest form of communication, transfer of information, transfer of meaning is two people face-to-face in front of a whiteboard. Whatever kind of team you have, you wanna get as close to that as possible. So if that means special electronic mediation or special timing or travel or whatever that means, that's what you do for distributed teams. That's the short answer. Okay, so gather data. Let's go, this is the next step. So gathering data is that probing. It's that, what's going on here? Let's make sure we understand the experience we just had from everybody's perspective, right? We wanna know from everyone's perspective what's going on. And so we use tools to help get that out so that everyone can see what everyone else is thinking. Sometimes if you were out sick for a couple of days, you had a radically different experience of a sprint than the people who were there the whole time, right? That can really happen. I'm gonna keep moving through these pretty quickly. There's big to more time for questions at the end. So this is a chart we call FRIM. Timeline is in the book, there's some others. FRIM is frequency and impact. You ask people to put on sticky notes things that happened during the sprint and then you have them make a judgment call about was that a positive thing or a negative thing? And how often did it happen? Did it happen all the time or did it only happen once in a while? And that gives a, it's a visualization of the sprint. I mean, a lot of the retrospective work is about visualizing what has happened or what the thinking is. So that's one. This is another really simple one but is very effective in highly complex situations. How was this sprint the same and different than the last one? So in what ways was it the same? In what ways was it different? And which of those differences, what this last column over here is, it's Russell Lakehoff, differences that make a difference. Which of those differences really made a difference for us, right? Here's another activity where people, get in pairs and they go around and they write about their experience of the sprint and then see what other people have written and then see what other people have written. It's gonna go. Okay, so after we've generated the data or gathered the data, now we all have a common understanding of what this iteration or this sprint was like and now we're ready to make sense of it. Right, now we can begin to do the sensing part. We call that generate insights. The HSD folks call it the so what. So what does all this mean now that we know, right? So things like in the book we have a lot of short subjects. This actually is where, and so now given what we know, what worked well, what would we do differently might fit. It is not a whole retrospective in and of itself. I cannot say that often enough. So, but there are a lot of these things that you can use and it's interesting they all, they all have a certain similarity but depending on using different words you get different outcomes and different perspectives. So calm, keep add less, more, same more of less of prouds and sorry's. What are we proudest of during this sprint? What are we sorry about? What do we do well? That four questions also comes from Norm Curth. What do we think we did well? What have we learned? What would we do differently? What are still puzzling us? Here's another set. This also is from the HSD Institute. Pattern spotter questions. Once we get a frame chart or a timeline or something visualized up on the wall then we ask ourselves. So as we look at this in general what do we see? Where are the exceptions? Where are the contradictions? Where are the surprises? Where are the puzzles? This one is another good one of having people like write up issues on sticky notes and then say well which of these are within our control and which of them can we do have some influence over and which of them can't we influence? And that tells us something about what kind of action we can take. Things we control we can take direct action. Things that we influence we may have to think about some kind of persuasive or recommending action. Things that we don't have any influence or control over well what we can do is figure out how we wanna respond when this comes up. This is the classic vice president coming in the middle of the sprint with just this one extra thing to do. How are we gonna respond to that? We cannot change his behavior. We have probably very little influence over him but we can change how we respond. So those are all generate insights things. How do we make meaning of the data that we have? And then once we have meaning we can say okay so what does that tell us about our next improvement action? Our next experiment. What are we gonna try? What do we wanna learn and what does that tell us? Maybe it's kind of like a team level minimum viable learning I guess something like that. And so from that you can say well if we've got one of these charts let's start with the thing that we have the most direct control over but we can take the direct action on. That's usually a sweet spot. We're probably more likely to get quick success or some fast action there. This is another chart. This is called moving ideas from ideas to action. Have people after doing the generate insights have people suggest actions that the team might take and then we put those up. We say how much of the team's effort is that going to take? How much positive impact will we get from it? How much real energy does anybody on the team have to pursue this and who's willing to make a commitment to make it happen, right? Actually it's very interesting because when things show up in this column as being highly impactful but people have no energy for them we always go with the thing that the people have most energy for. They'll come back around to that other stuff if they need to. Okay and then finally closing the retrospective. We've got our improvement action we're ready to move forward. We remind the team of that. We now get some feedback on how did this retrospective go and we appreciate everybody's effort in the retrospective. So we might do an offer appreciations activity or we might do, this is called a learning matrix. And some teams do this. In the book I drew the chart that looks like this and my flowers look like broccoli but this is a nicer one so I use this one instead. But it's, you know, what went in this retrospective what are we feeling good about how we work together for the retrospective? What could we do better in the retrospective? What new ideas do we have for future retrospectives and who do we want to appreciate, right? That's another way of doing it. Here is our friend of the face report again. This is how they felt at the beginning. Here's how people feel at the end. And finally, it's really important to make sure that you've got a good return on the time you've invested. And so it's helpful to check that out, right? Do we feel like we, this is like an hour and a half of our lives we're never gonna get back again and it's totally wasted. Does it feel like it was about even, you know? We got about the right amount of value for the time we spent or did we get more value than we might otherwise expect out of this amount of time. This is a really good one to sort of figure. You can, and you can actually pair this when I've seen folks do this where they will set up the chart and have people just put dots on here instead of doing the tick marks. And then across the bottom they'll have a keep drop add so people cannot actually make some more commentary on it. Okay, so that was a fast, fast move through those. But this is the model. So you do the work, you incorporate the experiments and improvements from the last retrospective. You do the work, the building the product, you do that building work. You come into the retrospective with a set the stage, gather data, generate insights, decide what to do, close the retrospective and go back to work. So it's a constant flow, constant flow. So there are your reminders. Set the stage, gather data, generate insights, decide what to do, close the retrospective. So now let's spend 20 minutes, 18 minutes putting together a design for the person at your table to take back and try out. Get as far as you can. Think about the preparation things. Think about what activities you might do. Some of you may have great ideas about activities that I didn't represent up here, that's fine. And see what you can build. And if you need me, hold up your hand, I'll come help. OK. OK, we're going to have 5 more minutes. So we're going to move right ahead here. So in terms of thinking about the retrospective design, do you know how many of you know what kind of retrospective you're having? Is it a sprint, or a release, or you defined that? OK. Did you talk about the complexity factors? OK. Did you talk about when you're going to have it, where you're going to have it, how long it'll last? OK. OK. Who's going to participate? There was a lively discussion at this design table over here about whether the manager is in the retrospective or not. And it is not a cut and dried answer at all. Did you talk about how you'd set the stage? How you'll gather data, generate insights, decide what to do, close the retrospective. Did you talk about how you will sustain the learning and improvement actions after? We didn't really, I didn't really prompt you for that. But I wondered if any groups would get there. And who at your table group is going to use your design flow? So the person who's going to use the design flow, raise your hand. Do you feel ready to take your design and go and work with it? Yes? How about do you feel like you're ready to take your design and work with it? I lost his attention. Do you feel like you're ready to take the design and work with it? OK. What about over here? Yeah? OK. So who else besides these three is going to take your, and you feel like you've got enough to begin to work with? OK. So the four of you come up here. Was there anybody from this table? The four of you come up. So the guinea pigs. I mean, it takes some guts to sort of expose what you're going to do. So you're all feeling pretty satisfied with the designs you've got? So what is the focus of your retrospective? So it was a release record. And we were focusing on how to gather data from different kinds of teams. Different teams. OK. Here. Better at the engineering practices. Always a perennial favorite. Yeah. Oh, so how are we going to deal with the uncertainties? OK. So it's a migration. And we should do it the way the client wants it. A focus on migration the way the client wants it. OK. Dependency with the legacy systems. Dependency with the legacy systems. So which of these do you think is going to be most difficult? We'll do a round of applause. The dependencies with the legacy systems? OK. The migration. The dealing with the uncertainties in the situation? Yes. OK. The engineering practices? And cross the team. OK. Well, so the applause meter says you get the book. OK. Oh. OK. So we need to keep moving on. Continuous learning and improvement means changes. So even though we have the retrospective, we also have to think about what comes after. And what we're talking about is instilling, sort of what Dave was talking about this morning, we're talking about instilling change as a way of doing business. It's as a constant, right? And that needs organizational support. So coaches and scrum masters, you need to be talking to the folks who, I mean, this is an area rich in impediments, right, that you'll need to be focusing on. I find that getting people the right information, giving them the right structures, giving them the right kinds of support is a big help here, but it's not the only answer. So online resources, there are a number of web, I told you about the books, there are a number of websites. There's a great one called plansforretrospectives.com. Corinna Baldoff has put this together. It's awesome. You go, you hit a button and it spins around and it gives you a retrospective design, which is almost never the exact right retrospective design for you, but it's a great starting point. Liberating structures is a little bit more sophisticated facilitation techniques, but some, and they're really ordered from simpler to the more complex ones and as a rich source of group processes. The McCarthy show, the core protocols is another thing to be paying attention to. Paolo Curroli has a website called funretrospectives.com and he has whole designs there. There is a retrospective wiki that has a lot of different activities on it that they've collected. There is a Yahoo group, retrospectives at yahoogroups.com. If you do retrospectives, hyphen, subscribe. Well, Automatic, it'll get you signed up for that. I know the moderator really well. It's Esther, she'll let you in. And then there is also a retrospectives LinkedIn group. Once a year, we have a retrospective facilitators gathering. At the moment, it goes back and forth between the US and Europe. So this year it's in the US, near Lake Tahoe. Last year it was outside of Budapest in Europe. Well, I wonder if you might not want your own. And so if somebody is interested in starting an Indian retrospective facilitators gathering, get in touch with me and I'll tell you how we've structured the other and how that works. So, what's your plan? How are you going to get better at designing and facilitating retrospectives? That's the question I want you to walk out of here with. My wish for you is that you stay in inquiry, not in certainty. And we will deal with additional questions in the hall because I know the next folks need to get set up in here. So thank you very much for coming.