 So Diana, when she first found out about this conference, I think she was the most enthusiastic respondent. She's like, I want to do this, let's do it. So I really love her topic and I'm excited to hear what she has to say because I think in many respects this is the key to fixing what we talked about earlier where the word is across the chasm but agile perhaps hasn't. So I'll turn the time over to Diana. Take your way. Yes, I'm Diana Larson. I wear a number of different hats in this community. I'm the first hat that I wear that I sort of entered the community with is I'm a consultant with a company called Future Works Consulting that's based in Portland, Oregon, and no, I wish I got to work there more. I end up traveling quite a bit. I also, after that, I wrote a book with Esther Derby, which we pair wrote and we used as many, we just had a backlog that we pulled from and we used as many of the agile practices as we could as we wrote this book just because it made us feel more like walking in the talk which we want to do. So this book. And currently I'm chairing the Agile Alliance Board of Directors. So if you have any questions about the Agile Alliance and what it does or what it doesn't do or what you'd like it to do or comments or anything like that, please feel free to come up and talk to me over the next couple of days. I'd love to have those conversations. And I would be remiss if I don't remind you of another conference that's coming up later this year, the Agile 2009 conference at the end of August which is the biggest Agile conference that goes on. I can't know. I don't know that I've claimed that it's the best but it is the biggest for sure. It's international and this year we had over 1,500 submissions and that group of 1,500, mostly really good submissions was culled down by 80%. So that only 20% were able to be accepted and will show up in the conference this fall. So it may not be the best conference in the world but it's going to be pretty darn good. And Johanna tells me I should say it will be phenomenal. So Johanna knows. So we have come here to talk about principle number 12. I always like to kind of go back to first cases and so when I heard about Agile Roots and we really wanted to be talking about the foundations and the fundamentals, I said, okay, so I want to look for principles. So I picked out a couple of them and I said a couple of ideas to Andrew and I said, well, you know, what of these should we do? And the reason I like looking at principles, the values are great and as somebody said to me today, yeah, but you know, in some way they're kind of abstract and they're kind of motherhood and apple pie and how do we really know? And it's like principles really are statements of values in action. If we have these values, what does it really look like? And so here's something that you could actually recognize. If you're working in a team, is that team at regular intervals reflecting on how to become more effective than tuning and adjusting its behavior? You can know if you're doing that or not. So I thought, well, let's explore this further. With Esther, I wrote a book about retrospectives in some circles I know as the retrospective goddess. And yet there are lots of other ways and so I wanted to explore some more about retrospectives but more about there are lots of ways to reflect on how to become more effective, tune and adapt. And so I wanted to talk more about the things that we know. I actually came to Agile after a long time of working in various forms of high-tech organizations and over time sort of evolving more and more into working with IT and more and more to working with software exclusively. But over that period of time, working with high-performance teams, spending a lot of time consulting and sometimes offering training and team development and how to make that shift and so on. I learned a lot about instructional design and I learned a lot about how people really make changes. And one of the things that I discovered is that learning really equals change. Once you've learned a new thing, you can never go back and unlearn it failing some kind of head trauma. It's yours. And so you take that now into consideration for everything that you do going forward. It's really easy to say we're going to tune and adjust, but until you've done it and have captured that learning and that has caused you to say, you know, I really think we want to do something a little differently than the way we've been doing it. You've not really been through that cycle. The other thing that the principal talked about was regular intervals. Well, how do we know what regular intervals are? How do we choose that? What are those? And how do we make the change, behavior change, when we learn? Once we've learned something, how do we then do that tuning and adapting as we move forward? So I also used a practice called appreciative inquiry quite a bit and it's based on five theories. And one of them is called the principle of simultaneity. And it says once you ask a question about something, once you begin to inquire in a particular direction and gain a little new information there, you've already begun the process of change. So a lot of principle number 12 is about gathering the learning that helps us change in the way that we believe will help us be more effective. So the act of retrospective, by the act of learning and then that causing change, you can think of retrospective as a revolutionary act, turning something around. And the way I know that is from a man named Paulo Ferre, which was his last name I have a hard time with, a Portuguese man grew up in Brazil, worked a lot in Brazil, and he posited something that he looked at that he saw a lot with the people he was working with that he called the action reflection praxis. He wrote a book out of his observations called The Pedagogy of the Oppressed and he explored the role of learning and change. For in his instance he was looking for people who wanted to, you know, oppressed people who really needed to improve their living conditions, which I thought was interesting because when I first started talking to some of the 17 people who were in Snowbird back when and I asked them, well, why did you, you know, why are you using, you know, why are you promoting these new methods? Why do you want to do this? I started hearing a lot about sustainable pace and I started hearing a lot about well, we really want to improve our work lives. We want the work lives of people who develop software to be better. And that got reinforced for me about a year and a half ago when the Agile Alliance Board got together and said, you know, people know about the word Agile. That was part of the original charter for the Agile Alliance was to sort of begin to spread the word, let people know about Agile and people know some things about it now. It's more widely known. Is that enough of a purpose for us at this point? And the Agile Alliance Board said, no, it's not really. We need to, we need to get developed for ourselves a larger purpose. And as that group of 12 people talked what emerged out of that was a purpose statement that said we want to support and encourage those who are using Agile methods in order to make the software industry more productive, sustainable. So there's still that underlying we're learning in order to make our work better and our work lives better. So Retrospection Revolutionary Act. Some of the things that Paolo had to say about this, liberation is a practice, praxis. The action and reflection of men and women upon their world in order to transform it. That's what we mean by tune and adept. Make a transformation in how you're working. Reflection upon situationality is reflection about the very condition of existence. Critical thinking by means which people discover each other to be in a situation. We want to understand more. We stop and reflect because we want to understand more about the situation that we're in. Because from that understanding, from that learning we know we can make the change. And I love this last one. People are fulfilled only to the extent that they create their world, which is a human world, and create it with their transforming labor. In other words, it makes much more of a difference if we are the ones who figure out the changes that need to be made if we are the ones who implement them. So that is us tuning and adapting. And I was listening over, listening to the experience reports next door. And so one of the things that I heard was from Peter Green. Retrospectives were extremely powerful for our team in making this, meaning Agile, work for us. And then he went on to say, it's because it fostered team self-discovery. Our team invented test-driven development for themselves. He talked about how that was much more powerful than having somebody come in and say, you know you're about at the time when adopting test-driven development would be good. Let me show you how to do that. They figured it out for themselves. Through reflecting, through tuning and adapting, they became more effective. So another place that these ideas come from is from the lean world. And I don't know how many of you are familiar with the PDCA, the Plan-Do-Chet Act, also known as the Shoe-Heart Cycle, sometimes known as the Deving Cycle. Although when Deving talked about it, he talked about it as the Shoe-Heart Cycle because Shoe-Heart was one of his mentors. And he learned this method in collaboration with Shoe-Heart. So planning means to establish objectives and develop processes to deliver results aligned with expected outcomes. Have an expectation. We plan to achieve it. We just determine what results we want and how we're going to deliver those. Is that implementing that process? And what's interesting to me about this is that Shoe-Heart and Deving actually added an addendum to that which was not only implement the process but on a smaller scale where possible. Which sounds to me like a focus on small teams and small chunks of work and doing things in smaller time boxes. Check is compare the actual results against the expected results. An act is analyze the comparison. Seek the root causes of compliance or variation. Determine where to apply changes that will create improvement. And one of my sources said each complete cycle increases our knowledge of the system under study. So earlier today I made an assertion that what we really need to be looking at was how our systems were influencing our behavior. This opportunity to reflect and tune and adapt gives us an opportunity to look at the system. One of the things that I've been a little concerned about in the move to Kanban which I think has a lot of merit and is a good movement in that direction but I hear a lot about well now that we've got Kanban we don't have to have any kinds of team meetings we just take care of things as they come along and we certainly can toss in the time we had previously spent on retrospectives out the door. And my wonder when I hear that what I get curious about is so you're gonna get really good at single loop learning by stopping and fixing things right in the moment when do you get to double loop learning? When do you get to looking at the overall pattern of the kinds of issues that are coming up? It seems to me you do that when you actually take time. So in the checking and acting part we do root cause analysis in PDCA. We use lots of different tools. We use an Ishikawa diagram and I think you're familiar with that also known as the fish bone where each of these large bones of the fish get labeled. Some people use five P's we have a bone for people and product and process and plant or place and protocol and then we look at the impact of each of those parts of the system on the issue that we are actually trying to look at in the moment. Other causes that people sometimes label those bones with are marketplace, benefits, location, maintenance, environment, transport, skills, communication, policies and procedures, equipment, methods, material measurement or metrics and management. We can really look at some big chunks of the system and how it begins to affect sometimes this is called a cause and effect diagram too. How can those parts of the system which we know influence it influence the behavior? How are they influencing behavior in this particular case? So moving one step up and just fixing what's in the moment to a larger consideration of how really is the system making this happen? So for example, so take the example of a team that does have a combine board and they've got it clearly labeled we can take three cards work in process and yet week after week they notice that five cards are showing up in the column. Well the simple fix for that in the moment is just oh move the cards back, right? These two don't belong there. It's not, we figured it out. But why are those cards showing up there? Well so-and-so is moving them. Why is so-and-so moving them? What are the pressures? What else is going on in this system that's causing that behavior to happen? Some other ways of doing root cause analysis is really stopping and analyzing your system and what's going on. The five wise. Five wise is a wonderful tool where we ask why five times. Have any of you used this one? Yeah, it's great fun and it's great fun to map it so that you start out with a question and then you answer that question you write that answer down and then you transform that into the next question and you go on and on. Sometimes there's branches. It's very exciting. But eventually you get to a place where you're saying well and then you know you've reached it. If you push through that and you can't get any further you know you've probably reached a root cause. Just the other day in a workshop that Jim Shore and I were doing in Portland some folks used the five wise to look at a problem and it was fascinating because they were not they were not delivering a piece of their process that they really wanted to deliver. They just weren't doing it. And yet when we asked them well it's just because we're not. We said well why aren't you? Well we've got this reason. Why are you doing that? Well we've got that reason. But why are you doing that? Because we never they finally got down to it. We weren't doing that because we never really defined on our team what done. So it was allowing us to get sloppy on that. So the very next iteration of the work they were doing they went back and the first thing they did was hold a little planning session and define done for themselves because they could identify that through five wise. And what was interesting about that is that we actually did go on a couple of branches. There was at one point there was a question that could be answered in two ways and so we followed those down and it came right back to no definition of done in both instances. It's fascinating. Diagram of effects is a way of looking at how one thing might impact another when you've got a lot of different things going on. And there's a similar kind of tool that comes out of business process re-engineering that I've never actually been able to track down the actual name of it. It's a diagram of something that Esther Derby and I use it sometimes in our retrospective workshop and we call it goes into goes out at because that's what we do with it. We identify things that are going on in the system and we say which one impacts the other more and we draw a system of arrows until we have a big circle and we know what's affecting each other thing in the greatest way and then we look for the thing that has the most arrows going out of it and the most arrows going into it and that gives us some sense of where we need to look further for root cause. Another thing that's a lot of fun is flow charting. We were just talking in the very last experience report next door that Jeff gave and he was talking about the Kaizen events that he has in his organization and how part of that is mapping out the process flow and that can be very useful and as he was describing it in similar to in a way that I used to use it many years ago have people map out the flow they think they have and then go and actually observe people working and map out the flow they actually have and compare those two and look for the bottlenecks and pinch points and backward loops where things travel through the same hands more than one time and all the handoffs and then design the flow that you want to have and look for ways to begin to put that into action. So both of these, the plan do check act and then the tools that you might use in a Kaizen session or a root cause analysis session all are ways of reflecting that have been around for 20, 30 years but the roots of our reflection tuning and adapting are in these things. There's another technique out there but long before I started really using retrospectives and calling them that I used to do a thing with groups that I called debriefing debriefing and then action steps very similar very similar to postmortem often stops before the action steps but this has been around and one of the best tools that I found for helping a group move through that because the really tricky part in Agile is not taking a group of really smart people and having them make decisions because all of the individuals in a group of really smart people are fully capable of learning they learn what they needed to know to get where they are they know how to think things through they know how to make decisions but they very often have not done it as a group they've not experienced what it's like to learn something as a team or as a group or think about something as a team as a group so that it becomes the teams learning not just the individuals learning but it really comes into the DNA of the team as an entity and certainly many folks deciding as a group knowing what's the best approach for this decision who should really make this decision how should we make this decision and what happens a lot is teams go automatically to well since we're a team everything must be a consensus and so they start wasting enormous amounts of time trying to go into consensus over are we going to buy the chairs Herman Miller or chairs Sid for less we're going to go for lunch at Applebee's or Red Robin those are decisions you don't actually need consensus on because probably whatever chairs you buy and whatever restaurant you pick everyone's either going to sit on them or eat there without much problem with that unless you have someone you need to really take care of because they need a special chair or they have a special diet so teams can delegate those decisions some of their decisions to the people in the group they think are best capable of making them once in a while there are decisions that a whole group needs to make for itself and as a way of helping groups think together it's useful to go back to what we know about how individuals think because groups it's very interesting groups, teams departments, organizations if you begin to really study them you discover they're kind of fractal and so things that humans do you see happening in teams the whole teams will do humans go through stages of development their musculature develops at different times they're capable of taking on different things some people talk about the terrible twos or the rebellious adolescence or whatever how many of you are familiar with for the forming, storming norming model teams go through that they do the sort of starting out in life kind of phase and the rebellious fighting among ourselves phase and then they get to the we've got to get down to work phase and so on how do we help teams think together well it's useful to look at how humans think how do humans think about something, how do they respond in a situation so we take in some data through our senses we have some kind of response to that data we reflect on we have a subjective we take in an objective data we have subjective response to that we then make some meaning out of the whole thing we probably have more subjective response to the meaning that we do and then we actually based on all of that take a step here I am you know walking forward take in the data that says the next place on this floor looks about the same as this one I feel pretty secure about that I could move forward but my foot out here oh there seems to be my data tells me there's nothing under there that seems a little scary I think I will choose to pull my foot back not step forward there that's just how we do things so we can help teams in the same way by taking them through a process or any group of people through a process very quick of by asking them some questions questions about the sensory data around them that they can observe in the thing that we are thinking about right now what have you seen what have you heard if it's appropriate what did you taste or smell so we ask that kind of objective data and then we ask for some subjective data what was your subjective response to this positive, neutral or negative so what pleased you in this situation what surprised you what challenged you what repulsed you where did your energy go up where did your energy go down we look for that information once we know that then we can ask a group of folks questions interpretive questions questions about for analyzing finding root causes implications insights how was this like some other situation what worked well what would you like to change if you could change something what insights do you have reflection and then finally we move on to that question about how are we going to act decision questions questions that stimulate action what new action would you like to try what's one thing you'll do what's your next step so you can lead a team through these kinds of questions and it helps them to reflect on the situation they've just been in and make some decisions about how to move forward this process is well documented in a book called the art of focused conversation by Brian Stanfield at all and it's a very very useful book because not only does he describe this process of oran which we call it or as some folks call it what gut so what now another way of thinking about this but they describe this and they give many many many different kinds of group meetings group situations where you might ask these questions and give sample questions to ask so it's you can go there and sort of pull out questions you know is my team doing something that feels more like planning or is my team doing something that feels more like we're dealing with a conflict that just came up or you know what are we dealing with now how can we stop and ask ourselves the questions that will help us if they decide together so so far I've talked about the plan to check act cycle and the root cause analysis and oran and all of these are ways but what about who does this and when do they do it so for many many years a military has had a structured review or debriefing process of initially developed by the US Army and now used widely in the military and also by firefighters and other defense and emergency preparedness organizations for reviewing what they plan to do in their situation describing what actually happened analyzing why it happened discovering how it could be done better and then making recommendations for how to move forward further the after action reviews it is mandated are done by the people who were involved and those who were responsible for the event so all the stakeholders it's intended for the evaluation of an incident or project in order to improve performance by sustaining strengths and correcting weaknesses performed as immediately after the event as possible the one of my sources is the wildland fire lessons learned system center wildland fire lessons learned center and they have actually a form that's called the AAR roll up it looks like this after action review AAR roll up lessons learned center you fill in the incident and the the unit or who was involved and who's submitting the report and the dates of the assignment and you have to answer all those questions what was the most notable success what was the most difficult challenges so you have to have had this conversation about reviewing and describing and analyzing and discovering before you could fill out this form because it calls for the answers to that thinking together and then there is a place where the recommendations go what would you recommend if future teams got themselves in this kind they've been doing that for years and the firefighters the US firefighting academy in Washington DC has an enormous database that you can go to that tells you all the if you want to read about any fire anywhere that you've ever heard of happened in your own town or something some big disaster that happened somewhere else in the US you can go there and read the after-action review on it because it's public public domain so are you resting your hand? I'm just resting my hand well I noticed the thing so but I wanted to check so which brings us to retrospectives a lot of the information that I've just talked about is the understanding underlying why Esther and I wrote the book in the way we wrote the book so we say when you're doing a retrospective you begin by setting the stage how people kind of get their minds and bodies in the room ready to do the work ready to begin to think about what they're going to be talking about during setting the stage we choose a goal or a focus for this particular retrospective we gather data what do we know about this iteration or this release that just ended what do we know about it what do we see and hear what events happened and we generate insights so given that those kinds of things happened what are we going to do about that what do we think we would like to do about that what does it tell us about our ongoing work where have we seen this before what did we do well and then the team together decides what action they would like to take have a lot of recommendations about limiting that to a very small number particularly for iteration retrospectives because you want to make it doable for the team want them to actually achieve success on this and then you close the retrospective and that's a time to recap what you discussed what you learned what you thought about what you plan to do and also to take a few moments to continuously improve the retrospectives do a little feedback on that so I've just talked about a whole bunch of different ways of reflecting which can move into tuning and adapting are they the only ones are these the only ones no at any time in a team you can offer appreciations there's no way of giving feedback letting somebody know a way of reflecting on a behavior incident giving and seeking interpersonal feedback as well reflecting on what has just occurred and having some conversation about that debrief pairing sessions I know lots of pair teams and teams that have a they say at the end of every pairing session we have to stop and just answer a couple of questions what happened this is a good place to use word what just happened while we were what did we see in here while we were pairing were our highlights or challenges what are we still puzzled about do we find any opportunities for improvement here what do we want to try next time be paired together be very fast but it's very effective at increasing tuning and adapting the stand-up meeting asking the four questions data gathering right what do we do yesterday what do we plan to do today looking forward a little bit what's in our way and I love the fourth question that Mitch Lacy has added and on a scale of one to ten what's your confidence it's a lot of information there objective data and subjective data the team then can do something about a decided we want to now have an extra meeting to look at how we want to clear this impediment Alistair wrote about mid iteration reflection workshops during the first couple of iterations that a team is working together not waiting until the end of the iteration but stopping halfway and saying how are things going so far what's going on keeping them very short just fifteen minutes but just to check how we do it the Dr. Phil question how's this working for us in the project retrospectives Norm Hearth has written about holding larger retrospectives at the end of a project where everyone marketing, management everybody is present because all of those people have a role to play in getting the software out the door and looking at how we are doing our projects and how we might want to do them differently looking for continuous improvement at the organizational level in terms of how we organize support and run projects Jeff reminded me in the last session about things like Kaizen events where at one time we called quality circles too where we get a group of people together and they huddle around a particular issue or problem and really dig into it until they come out with some recommendations for how things work differently so those are a lot of the how the team can tune reflect tune and adapt ideas that I can think of but this is a workshop and so I want to move from the things that I've been able to think of to the creation of some new things that we might do so what I'd like you to do is create yourselves into some small teams maybe 5 or 6 people at around a table and design an activity for a team to learn together, think together or decide together what I learned in instructional design was test first people who are professional writers of training always write their training objectives first what happens that someone that this group or this person will be able to do after this experience that they weren't able to do before it you always have to do that when you're writing so design an activity and write your test first what will people be able to do after this activity and then write up your instructions on a flip chart include the title of your activity the purpose or objective as if either of those is a constraint and step by step how would people walk through this and then we'll report them out you have all everyone in this room as a resource can you talk to anyone in here that you'd like you can refer to the book unfortunately that's the only one I have that people in my last workshop bought all my spare copies and I have no time to work anymore so you'll have to share the book if you want to use it we've got hosted notes and sharpies and sticky notes of various sizes and kinds and all kinds of supplies up here for you to work as a team learning about reflecting, tuning and adapting thinking together about it and deciding on a way that you can help your team do the same thing it's a little recursive but I think it'll be fun and I'm more than happy to serve as a consultant to any team that says you want me okay I'm not so interested in stand-up meetings but I think it would be really helpful for my team if after every story was completed we took time for some reflection this may not be something you would choose but so that would be your opportunity right and then you'd say well so what would we need to do to learn about how could we learn about, how could we think about how could we make decisions about story completion at that point how would I want to be what learning would I want to come out of that or what action would I want to come out of that in terms of teams learning and thinking together and how would I write that as objective at the end of every story the team will do this and so instead of what they're doing now so if I stuck with that one so after every story gets moved into the done column we're going to have a little huddle and we're going to only the people who have worked in a pair that worked on that story are going to come together it's not going to be the whole team but it's going to be a subset of the team we're going to come together and we're going to talk about how correct our estimate was for that story where we did we feel like we were on target or were we way off and what affected that and we're going to ask ourselves what we saw in this story that caused us to estimate the way we did and what we saw in the story that we think helped us write the code for it and what we thought got in our way in writing the code what made it harder easy and then we're going to write up a little report but write a little report about how we're how we're handling the throughput on stories and we're going to deliver that we're going to have some time set aside for that when we do have our retrospectives for us to report on how we're handling stories if you thought something like that would have value for your team the test first would have been we're going to get together and by as a result of the activity people are going to know more about stories and we'll be able to tell that they know more about stories because they'll be able to talk about a particular story in depth okay so we'll take we've got about 45 minutes for this so we want to hear what everybody has to say so we'll take about half an hour for this and at the end of a half hour or actually after about maybe 25 minutes hear that sound and that means take a couple more minutes and wrap up because we're getting ready to present the things that you create the activities that you create and we're going to move this flip chart easel up here you'll be able to bring their pieces of paper on most of the tables then on all of them that's where you write up your activity and you bring it up here stick it on an easel and report it out and then we'll all be done by five so how can we reflect tune and adapt how can we find new opportunities for that