 Okay, so I'm here to talk to you a bit about adopting Agile not as a big upfront thing, but via continuous improvement, and in particular, I'm focusing on your first five days and your first two years. The first two years focus is an important part of this, because two years is really just getting started. All of that will be as we go. So the first question is, why bother? This is actually the first thing that you'd ask on any Agile transformation. Why bother? Why is it worth changing the way that you work? Because any transformation, no matter how well it's executed, no matter how good the results, it will cost you at first. And there will be a lot of pain, and especially a change towards Agile from more traditional ways of working, is a fundamental cultural shift in decision making and in how status, authority and power are distributed around your company. That level of change in the politics and the culture of your company will not come lightly. So what is it that makes it worth changing? I always start with that question. And at my company, now I'm at Microsoft, so at my company the answer to why bother is we need to release at a higher cadence. So just a little bit of why you should bother to listen to me. So I've seen a lot of teams. I've been doing Agile, especially extreme programming since about 99. And with a wide variety of teams in a wide variety of circumstances. And since about 2006, I've been helping teams become awesome. And so I don't believe that there is one way to do things. I don't believe in best practices. They don't exist. There are, however, good practices and bad practices. And a lot of my goal is to help teams avoid the bad practices, such that they can choose between the good ones. So if you are interested in hearing more about that, then please stay. And if not, then there are some other talks. I believe strongly in the law of two feet. This is here for you. I get no value out of delivering a talk. You get value out of it, and that's where my joy is. So if you want to be in another talk, please do. So as we start looking at a transition, there's really only one fundamental thing about Agile, and sort of how it works. And this is a rule that you can start to use to identify the good practices from the bad. And that is, during the transition, first you're going to reduce risk. Then once you've gotten risk and cost down, you're going to leverage the low risk state. So what I mean by this, if we look at software development, it's a fairly high risk environment. When we decide to make a change, that has significant transactional costs. Every iteration that we release, there's a high probability of defects. There's a high probability of annoying customers. We have traditional extreme transactional costs on releases as well. And on many of the various processes, the ability to iterate requires that those costs and risks, for instance, be low. So the overall approach that I take is, first we drive down the costs and risks. Once we've driven down the transactional costs and risks, many new opportunities will arise. And then teams can choose between those. All too often, I see teams start focusing on the wrong thing. They focus on the stuff that you find online on continuous delivery and continuous deployment and lean startup and build measure learn and all these things, which is leveraging low risk state. All the teams that invented that had already solved their transactional risks. If you haven't solved them, you'll try that and it won't work for you. Because when they talk about shipping, they assume that I can deploy from the moment that a coder finishes coding to it is in production in four or five minutes in a fully automated process with zero defects every time. That's the state that you need to get to. You eliminate all the risk and then you get to do all of these really cool things. So the first couple of years, what we're gonna be talking about here, your first two years is all about reducing risk. So this is a point where I depart from many people. So you might remember Martin Fowler talking yesterday in his keynote about agile is at its core two things, collaboration and interaction in team-based software development and adaptive planning. And I think the planning is irrelevant. So at its core, I totally agree with him. The collaboration and adaptive development is a big part of it. The other part is, in my mind, that elimination of risks. The planning I see as one of the things that you can do once you've leveraged, as a way of leveraging low risk situations. So if you look at adaptive planning, it depends on being able to change our direction quickly and cheaply. It depends on having low technical debt. It depends on not having a lot of bugs. If you don't have those, there's an interesting quote from Sutherland at one point that I read that was, every successful scrum implementation I've seen has had technical practices as something like those of XP underneath it. Think about that for a moment, right? There are a lot of XP teams out there that are not doing scrum stuff. The scrum teams that are succeeding over the long haul are doing the technical practices, right? You need to eliminate the risk if you're going to plan differently. If you don't eliminate the risk, then lightweight methods, the lightweight planning, simply ignores a bunch of things that are really important in your domain. So this always raises the question, so what if we build the wrong thing? Jez Humble was talking about, in the middle of Martin's keynote, he mentioned only a third of all features that people develop bring positive value or advance the metric of success in any way. And about a third have no impact, and about a third are negative value. So there is this problem of what if we build the wrong thing? And planning at the point of it is to address that. But it's also worth pointing out that most products have many features, and that the law of averages says that if you compose a whole bunch of those, for the bad ones, you'll also get some good ones, right? And the things that decrease value have ones that increase value. And beta periods and the like are really good at finding the things that are strong negative value. So you remove those, so your product will have some positive value. Not as much as if you were able to have a really good process of only finding good things, but your product will have positive value. On the other hand, depending on which report you look at, only something like a third of projects actually make it to market with the features they were intended at the time that the market window opportunity is there. So your biggest risk in software development is not that you'll build the wrong thing, it's that you will fail to build. You won't get the thing out. What you will get out will be missing the key competitive features that you needed, or it will miss the market window. So that's why our focus on risk says that we need to focus on execution. That'll be our thing. So I alluded to this earlier. In the Agile transition, there is one required pain. Often pain indicates that there's a problem and there's something that you should fix and go deal with or maybe work around. But as far as I can tell, any Agile transition is going to fundamentally decentralize power. That's part of the way it works. When you talk about emergent teams, the things that Todd was talking about just an hour ago of empowered teams that are taking decisions out of management and executing them in the teams where you have more data and more information. All good stuff. Taking decisions out of management is taking the job of management out of managers. It is fundamentally decentralization. Now, there are a whole lot of other really good and in fact higher value jobs that managers can be doing. But part of doing a successful transformation is helping everybody, management and the teams make that transition to decentralizing most of the decision making and having management do the higher value activities that they could do as long as they aren't required to make all the calls. So often you'll see as teams go through Agile transformations, they shift from organizational structures that are hierarchical in nature and very block and where all the work is done via the org chart. Into things that you go all the way to the extreme of Yammer or Valve or one of those companies and they describe it as, we are a distributed data processing network. We have people that come together and they process information and they exchange information with each other and decisions get made and magic happens. And the job of management and reporting structures is to ensure that that culture continues to exist. It's a very different way to talk about your business, right? It's a very different organization structure. So, talk a little bit about recipes. This is how I execute transformations currently. So, at Microsoft, my job is I'm in engineering excellence. I help teams change, typically about 75 to 150 person team at a time. Do a bunch of those. So, the first step in any transformation, and this is the step that I do. Well, we're still in an authoritarian based decision making structure, which much of my company is, and many companies are, is to create aligned teams. Now, these are people talking about as cross functional teams or single assignment teams. The important thing about these is these are teams which have everything necessary in order to deliver business value, all the roles that are necessary. And where every individual human is on exactly one team. The most important trait of an aligned team is in monkey brain space. It is that I as a human identify with us as a set of people, right? Has nothing to do with our product. Has nothing to do with our reporting structure. It's if I want to get improvement in the way that we work. I want to have people help me improve and I want to help them improve. I need to have a set of people, right? So that is the key thing. If I am thinking of myself as a member of three or four teams or as a local team and a team of 100, then I won't have that core identity that allows me to really make my improvements. So that's the first thing. We need aligned teams and those teams need to be small enough that we can actually make changes and improvements and make decisions fairly easily. Eight is perfect. It seems to work very well. But a go around that and it still works okay. Find as teams get up to 12 or 16 or in that sort of range. They tend to naturally break into sub teams anyway, because people seem to cluster pretty well at the six and eight size. And so if they find themselves in 12, they'll form two teams of six. So once we've got teams, next step, drive out risk. This is mostly what we're going to be talking about here. So this is, say, a couple of years. So aligned teams, if I'm in an authoritarian place, once I can, all I have to do is convince one person, medium high level manager, that it is worth doing. And they could just make it happen. Nice things about hierarchies is they're very vulnerable. Any one person on a whim can change the company direction. So all I have to do is change one mind and everyone has to follow. So I'll use that to get aligned teams. Driving out risk, on the other hand, happens at the team level. And this takes time because this is actually changing the way that we work. That's all the habit change. So that's where we spend most of our time. Step three, real customer involvement. So when I'm driving out risk, I am paying some attention to the customer. But I'm still fundamentally assuming that planning and deciding what we do is based in much the same way that it was before. We've got smart people inside our company. We will listen to them. They will make statements and guesses and opinions on which direction we should go, and we'll go that way. And it works. Eventually, we get to the point where we actually have more access to data about what our real customers are doing. And we can really involve the real customers. We can do customer development and build, measure, learn, and design thinking. And all those good things that mean that what we're deciding to build is actually based on direct conversation with the customers. And then the last step, after you've gotten a bunch of those teams, is creating a culture of sustained change, company wide. So industry numbers, as far as I've seen, show that roughly over the last 30 years, there's been a doubling time on productivity in the software industry of about two years, two and a half years. So 35% year over year growth in productivity every single year. That is a viciously fast productivity rate. That whatever you are doing today, in two years, you will be able to do it in half as many lines of code. Whatever you are outsourcing in two years, it will cost half as much. And that's average. So if you want to be an above average team, you need to increase faster than that. You don't get this by making a change and then being in a new state and sitting in that new state for a while. The only stable state is our competitors are growing faster than we are. So we have to build in cultures that sustain continuous change and improvement. And that's where you really get to company wide agility. So we've seen a lot about the path through Agile fluency, the fluency model of Agile. This is the same thing, slightly restated. So in the original document, they talk about, number one, talk about customer value stories. The point of that in my perspective, and this is my personal perspective, so take it as such. Is that that's where a lot of the alignment for getting aligned teams comes from. I find just stories and talking about value isn't enough. I also need identity, that set of humans. And stories are not necessarily required. I've had a number of successes with Agile waterfall, for example, which is completely waterfall planning. Executed in basically by XP teams with simultaneous phases. And they don't talk about stories and that sort of thing. But there's great alignment on what we're doing. And there are teams that are focused and come together. And then driving out risk is level two execution. Real customer involvement is obviously directly across and so forth. So as I'm doing my transition, I look at what a team needs, in terms of fluency model. And I find that pretty much all teams need level two or level three agility. There are a small number that can get by with one star, with level one. If you have a product that basically, if you don't care about technical debt, then level one is good for you. This is the case for people who are creating mobile apps. A mobile app is only going to sell in the marketplace for five or six weeks, and then there will be no sales on it after that. Unless you happen to be Angry Birds, right? So there's no point in worrying about technical debt. Your job is to get it out to market and then throw it away and build the next one. Level one agility is perfect for you. You do not need to make the investments to get to level two. If you are in any other business, you probably need at least level two. So now let's talk about how you get those steps. First thing is I find a lot of people focus on what you can do. What practices you're executing. Maybe how well you're executing them, something like that. That focus often leads people astray. The real question is, how fluently can you do that? And this is what the fluency model is really talking about. If all I can speak of a language is 50 words. But when I need to, I can immediately pull the right word, no matter what my circumstance, no matter what's going on. I can communicate. Now, not well, but I can survive being in a place where that's the only language that is spoken. That has value. If I can do, if I can write well formed grammatical sentences talking about a thing. But I can only do that by sitting there with a dictionary and carefully writing and thinking it out. Then when I'm in a train station trying to get to the restroom, I have no options. I can't actually communicate. The results that you get are based not off of your proficiency and your capability. They're based off your fluency. If I'm working with code and I've got a team that does hair programming and TDD and refactoring, it does all those well, but it only does those well when it's fairly easy to get it on the test and when things are going well. And when the system goes down and things are on fire, they revert to their normal behavior. Then over time, the code will look mostly like the code that they write when things are on fire. Because making those messes is so much cheaper than cleaning those messes up. So if you want to get the good result, what matters is how do you behave when you're under stress? And that's your fluency. We find the teams that they might or might not pair, but when the life site goes down, they always come together and they pair a model. The ones that revert to higher discipline when under stress, those are the ones that get really good results in clean behavior. So I'm going to propose a set of degrees of fluency. We've got a lot of charts like the Agile Fluency Model that talk about degrees of proficiency and that say, get to fluency within a state, but don't talk about what that might look like. So the first degree of fluency in Agile stuff, relabel existing practices. We see this all the time. How many people have been in an environment in which the team went scrum in one day? And it did so by doing exactly the same things it was doing before, but calling the status meeting a stand up and so on. How many people have been in that company? It exists. It's pretty common. Now, it's important to recognize that actually has value. At that point, people are able to talk about the new ideas, and they're starting to pattern match them to their old ways of working. Not a lot of value, but they can start to think about things well. The next one is they're fluent when the coach is helping. They've got someone on the team who can provide knowledge and experience, and as long as that person is present, then people will behave in the target way, whatever that team's target way is. And it's not that that person is providing the discipline. It's that that person is providing the skill, the facility. The next one is when I have seen a situation like this before. So if I'm working in trying to get some code under test, I have seen this particular hard to test thing before. I can get it under test, but although I figured out a whole lot of things of how I might test around the edges of GUI, I've not figured out how I might test around the edges of a network. So when I see a network, I throw up my hands and I can't get it under unit test. I can perform well when I've seen some situation like this once before. The coach shows it to me once, then I can do it forever. The next one is in new situations. So I can now take that concept and apply it to new contexts. If I am refactoring and doing design, I can run into a problem for which I decide that mocks aren't good enough, and I'm going to go towards simulators or something like that. Once I implemented that in this one area, I think about, oh, and that concept is a lot like this other concept I've seen over here. And I cross-apply that to other domains, and I start rolling it throughout my code. This level of fluency, you're consistently cross-plying everything. And then the last level is under stress. So let's talk about risk. Where does risk come from? Well, let's look at the typical release schedule. And this is not uncommon for my company and many other companies. I don't know whether it's common for you guys. But there is a predictable portion of the plan wherein we plan and code. And then there is a random portion called the stabilization period, in which we clean up all the messes that we created while planning and coding. And I find very common the ratio is about five to one. So you spend a sixth of your time coding and adding value, and five, sixth of your time fixing the problems that you created while coding and adding value. That's pretty typical. It varies a little bit. I've seen teams as high as like 30% of their time adding value. So where stabilization comes from? Well, what am I doing during the stabilization period? Finding and fixing bugs. So the need for stabilization comes because I have bugs. I have chosen to write bugs. Now I have therefore chosen to find and fix them. So how many people have been on a project whose bug database graph looked a lot like this? Yeah, pretty common. Write some bugs, find and fix some bugs, and then write some bugs off and end up with more bugs at the end than you did at the beginning and keep going iteration after iteration. So the question, if stabilization comes from bugs, then where do bugs come from? Now I mentioned teams have chosen to write bugs. Probably wasn't an intentional choice. They probably didn't think right now, I think this would be a great place for a bug. I'm going to write it and then forget about it so that we'll have to find it later. They made a mistake. But it's important to realize bugs come from human error. They come from mistakes. They come from humans. They don't spontaneously appear. They aren't a necessary result of programming. They're a result of programming the way we program. And then we can look at, so what are the circumstances under which humans make mistakes? There are edge cases, you know, humans make mistakes when they don't have skill. Yeah, that's true. On the other hand, software developers that are on my teams have generally been doing software development for a very long time. Even if they're new to my team in domain, that doesn't last long. They've been in my domain fairly long. It's not a lack of knowledge or ability. There's a system going on that's causing them to make an error. As we're working, we have a limited amount of working memory and attention. Our brains are only capable of handling so many different things at once. Keeping them all in mind. And there's a theory called cognitive load which talks about the amount of that space that is necessary to handle any given task. As cognitive load increases, then our facility with doing the task decreases. And in particular, when cognitive load gets high enough that it exceeds our working capacity, which is actually fairly low, then we now start making decisions based on a subset of the data. We start deciding how to change this code based on only some partial and local knowledge. We make mistakes. So bugs come from excessive cognitive load. What in our system makes things hard to think about? Some thoughts? What are some things that make things hard to think about? Hard to reason over in our systems. Size, absolutely. I work on it with a couple of teams who have 250 million line of code projects. It's very hard to think of all of that. What's another one? Was that? Data? What was that? Data conditions. Data conditions, yes. Yeah, so data conditions is a special case. So special cases in general really do. And special cases are an example of excessive complexity. Undue complexity. Programming and silos. Yeah, communication problems, certainly. Those don't necessarily cause excessive cognitive load while I'm working, but they make it so that I don't have easy flow of information and they'll get a similar result. Context switching. Yeah, yeah. Again, that one doesn't affect the cognitive load required to work with the project, but it alters how much you have to bring to it. So it causes bugs. So not knowing how the application's gonna get used. Yeah. Demotivation. That would again be a decrease in capacity. Yeah. So there are a couple of these things that we missed one. Illegibility. Code that is hard to read. If it is hard to read, it's hard to reason about, and that makes it more difficult. So in particular, there are a few things that are leading metrics of bugs. You can run them over a code base and it will tell you how many bugs you're going to have. And those things are cyclomatic complexity, direct measure of complexity. And size. And anything that gets towards illegibility. Illegibility is harder to rate and assess, but if you can do that, that also predicts it. So if you wanna predict bugs, you can look at those couple of things. So a lot of the practices, a lot of the changes that we're gonna make are all about eliminating those things. Switching contexts again. So if we're going to make changes to eliminate bugs by addressing this high cognitive load, well, we have to do that in a way that doesn't require high cognitive load. The transition that we're going to do needs to be simple enough that people can do it, right? And it needs to be supported. We're trying to get people to change habits, so we need supports for that. So an important thing from instructional design, cold cycle. This talks about how, especially how adults learn, but it's really how everyone learns, and adults have a narrower range of abilities to learn in other ways. Kids have a bunch of other ways. But it's basically, you go through this cycle. You have a concrete experience, you do something, and you see how it works in a real world situation. Then you have reflective observation. You reflect on what you observed. Then you have abstract conceptualization, modeling. This is where you think about your reflections and you get the idea of the theory or how it works together. Then active experimentation. Given that model and theory, you decide some experiments, how you're gonna run, and you try those out, and then you go back to concrete experience in the real world. And pretty much everybody has one of these that they skip. So each individual person actually has a typically a three-step cycle. And each person skips a different one. But this is the overall learning cycle that people go through. Now, if I were doing this talk well, I would therefore be giving you many more opportunities for concrete experience and reflective observation. I'm spending all of my time in abstract conceptualization. But as you're going through helping people do a transition, it's very important to go through this cycle. And it helps to go through this cycle with a small chunk. And then again, with another chunk that builds on it, and so on. The more times we iterate this cycle, the more effective the learning. So do that with small chunks rather than trying to do a big shift. So I opened up this talk with Why Bother? This is the mechanism that I use when I'm going into a team preparing for a transition for answering the question of Why Bother? There are a lot of people that I could work with. There are a lot of people who are trying to make agile transitions. There are a subset of those people who will succeed. And the biggest indicator of whether they will succeed is that they actually have a reason to do this. So this is pulled from the performance chain analysis. If you look at sixboxes.com, it's got performance chain and sixboxes, which is all about how you can work backwards from a business result that you're trying to get through the work outputs that will deliver that through the system and do some systems thinking and understanding of what systems will lead to those work outputs to the individual behaviors that drive that system. And then to the behavioral influencers that you have in place that change the individual behaviors. So as I'm thinking about doing a transition, I'm thinking about the end goal and then all the way back through the behavior changes so that when people are making some behavior, they know why they're doing it and they know when they're doing it in a way that is helpful or when they're doing it in a way that isn't so they can get that feedback and then go even one step before that and you talk about the influencers, the feedback systems, the support mechanisms. It's not about training. Training helps with one of those influencers but it's all the other things that change how a person behaves. So this I find, I'm gonna fill this in with the most common result that I see. And the way I'll do this is I'll go into a team and get their managers and their champions and all the right people in the room and then just open it up a blank whiteboard and we'll Q&A and go through this but I find there's a very common pattern to these days. And that is everyone wants to inspect and adapt faster and they want to decide based on data and experimentation. Those are the business results they're looking for. And in order to get there, if those are the business results, then in most contexts, not all but the vast majority, the work outputs, the results of the system need to be team oriented development, a cessation of individual development, changing to low risk and cost, making it low risk and low cost to make changes both to the team and to the team's code, and to change based on data. And then the behaviors that lead to that are sort of what I have as I call it Agile in 12 words or I guess it's up to 14 now. But work together, learn constantly, work tiny, prove it, get done, risk first and value questioning. Now, as I look at this set, this set of behaviors is fundamentally and the work outputs is fundamentally based on two things done over and over and very, very well. And so in a sense, I could talk about Agile is an expression of two practices. I don't know whether I will talk about it that way, but I could. So it really is if you are refactoring, refactoring mercilessly, taking a problem not as a big thing but making small steps that are known not to make the problem worse. You can prove don't make it worse. And then being able to take the next one and the next one and refactoring change your mind all the time. And then running experiments with measures and paying attention to those experiments, intentional experimentation. So let's talk about the chunks. If I'm gonna refactor a team, which is just how I talk about it, refactoring legacy cultures is a good thing. Then the first chunk is I need to make a team. So I mentioned that here I take advantage of the authority structure. And that's why I call this the real first chunk, but it's not the first chunk that most people see. Because by the time that most people are involved, this one's already completed. So in making a team, get the right people where the right people is far more flexible than a lot of people think, but you need to have whatever capabilities are gonna be necessary to succeed, at least one person representing them or at least someone who wants to learn that. And you need to have a reasonable number of people and everyone needs to be on exactly one team and you have to have that identity. So first chunk, make a good team. Recognize that change will happen side in during your transition. So change does not happen bottom up and it does not happen top down. Neither of those mechanisms work. When you try and do change from the bottom up, then you get good results because the people at the bottom of the hierarchy have all the data, they can make decisions, they have the knowledge, they take action, and it works great locally and it threatens the people on top and confuses the people on top and it doesn't have an ability to spread and eventually it gets isolated and killed. When you do it from the top down, the people who are making the decisions that are driving the change don't have access to the real information on the ground. They therefore end up making decisions which don't match what's really going on. And so the people at the bottom, I see them as clueless, they're informationless, not clueless, right? But they get seen as clueless and so you develop resistance at the bottom and the change fails. People only change their job based off of someone else who's doing their job. If I am a lead, I will not change the way that I lead people based off of what my manager says nor based off of what an individual contributor says. But I will look and see another lead doing the job well and I will follow him. And the same is true for all levels of the hierarchy. So what we're trying to do is allow every person to learn how to do their job better from another person who does their job better. So from the top, I need to create a zone of safety. From the top, I establish culture, help establish framing. It's not vision, it's framing, helping people understand the system. From the bottom, incidental risks and cost determined from the bottom, data comes from the bottom, knowledge and especially, and most decisions are made at the bottom even in centralized systems. There are just so many more decisions than you could handle through the central system that most of them end up getting made at the bottom. And then behavior changers come from the side. So as I'm setting up my teams, this is what I'm thinking about and I'm helping the managers understand their role and I'm helping the people on the teams understand their role and making sure that I will have people that can spread that behavior within each level all the way across. This means I end up with a couple of roles. So this is what a typical transformation team or whatever it looks like. Now, I sit in a central organization, so I don't own any of the transformations that happen. The teams that are being transformed own their transformation. There will be 80 of them or 150 of them or whatever. They're gonna decide whether they transition, they're gonna decide how they transition, and they're gonna determine whether it works or not. All I can do is sit from aside and provide experience and guidance. So the most important role is doer. This is basically everyone on their team. People who make decisions, people who take actions, and people who assess whether things work. It's managers, it's ICs, it's everybody. And so in the end, with a successful agile transition, this will be the entire role structure. We'll all be doers. But early on in transition, we're not there yet. So we need supporting roles. So the first supporting role is champion. The job of a champion is to represent an idea. Maybe a couple of ideas. So I might have a champion for refactoring. They really believe in it. They have a fair amount of knowledge about it, and they wanna bring that idea to the team. I might have a champion for our code is hard to deal with. Now, many people will call these resistors. They're the ones who say that agile can't possibly work here. They aren't resistors, they're champions. They're champions of a problem statement. They're champions of the way things are currently done. And the key trait of a champion is that they are listened to, they are understood, and that they are able to grasp some complex idea and help the other people on the team realize the value of it. And it is very important, the champion, the resistors, the champions of the old way are very important members of your transition because they're going to provide all the context and nuance and knowledge that will help you adjust what you're doing. So you don't have any resistors, you just have more champions than you planned on. So the next role is coach. When I'm talking about a coach for a transition, I'm meaning the person who facilitates team making. Helps people adapt to change. This is a person with high emotional intelligence, the higher the better. This is a person who fundamentally gets human system dynamics and is able to help people adapt to change and work through what's going on. Third support pillar is servant leader. So typically these are managers, not always, but almost all managers become servant leaders and almost all servant leaders were managers. So a servant leader, their job is to provide safety to experiment and to support a culture of continuous change. So these people don't solve problems. They make you able to solve problems. They create that culture. And they are different from champions and coaches in that champions are trying to promote an idea and help you build that. And coaches are very carefully focusing on a team and servant leaders are looking at the overall culture and community and trying to help the whole process go forward smoothly as things are changing. And then there's my role, my team, gurus and we try and replace ourselves with community. So teams that have done this before, all of the doers from those team become part of the community and support the next couple of people. And then we also have some people, the job of this is provide experience and alternatives. And in particular, we need to prevent best practice thinking. All too often people will ask what's the best practice? What's the right way that I could do this? What's the most effective way? We need to break that but still have people thinking that there are good ways and bad ways and we need to choose among good ones and avoid the bad ones. So there's not one way but there are bad ways. And then as I mentioned at the beginning of this slide, when I'm done everyone will be a doer which means part of the job function of all the other supporting roles is to work themselves out of a job. Once the transition is successful you will no longer have this role. You will just be a doer. So the first chunk, this is no longer the first real chunk, this is the first chunk that people see. And this is to be able to make a change in existing legacy code without adding a bug. Most teams that I'm working with have legacy code. The very rare one which is Greenfield is actually I find more difficult because teams working with legacy code have something in the market that's working. They have some reason to continue existing. And they have tons of examples sitting right there in front of them of painful things that didn't work well. They also probably have several examples of things that did work well which makes it really easy to get concrete experience and learn. You can take one of those painful ones and show here's how we can make a change and hey everything's better. So the first chunk that we'll do is how to make one change in legacy code without introducing a bug. And that is all about refactoring. So this picture is an interesting one to talk about refactoring. It comes from a story a friend of mine, Michaela talks about, she's building a house. She's building a house on a vacation property in the middle of nowhere. And she's building an agile house. So she chose to build the house out of Cobb. And the reason she chose to build the house out of Cobb is Cobb is a refactorable building material. She can put up a wall and then when she decides she wants to move the wall it's sculptable. She can bend the wall and put it where she actually now decides she wanted it. And in fact the way that she's doing it the roof is supported in many different ways and it's got extra support. So she can move walls underneath the roof. The only part that she can't move is the foundation. She dug a foundation and put a concrete foundation in. But everything else is flexible. Because of that she's able to do this in a very agile manner. She actually is continually refactoring the house. She'll try it, she'll live there for a day, decide she doesn't like it and wishes that there were a window in that wall and then there'll be a window in that wall. And she can continue to tweak and modify the house as she's living in it. It's all about refactoring. Same thing is true with the code. You don't end up with the perfect code by trying to set out and build it because you don't know what it is. You don't end up with the perfect house by just trying to set it out and build it. You will be disappointed when you move in because there are some things that you've figured out along the way. Whereas Michela won't have that problem because she'll refactor it. So the first goal of a team is own your destiny. Well the first thing I'm teaching people is refactoring. What I'm really trying to drive is not just the skill of refactoring and making a change without introducing a bug, but the culture of owning your destiny. So I talked about everyone's a doer. I talked about the servants. Everything that I talked about on how you structure the teams is I'm trying to create teams which can own their process, they own their product, they make the decisions. The buck stops with the team. Other people inform the team, the team makes the call. So that's the real culture they're going after. You own your destiny. And the first product, and so I get that by having the team refactor itself all the time. The first product goal is great names. There are all of the principles of good design and of course four principles of simple design. The second one of those is great names and I find that one is a very easy one to teach and in working with legacy code it's the most important one. It directly solves illegibility. Illegibility is one of the causes of bugs and risk. So it's a great opportunity for an early win. I can make code easier to modify just by getting great names in there. So I teach the simple refactorings, extract method, introduce parameter, introduce variable, and rename. Those are the only four you need in order to make great names. It's very easy to learn those four things. And then we can talk about naming and help teams get good names. Just doing that will drive down bugs in the code. And so you'll start seeing results quickly. So that's the first product goal, get great names. In both of these I'm talking about chunking and early value. I want the team to own its destiny. I'm not saying what they're going to do with that. They're not going to get great results necessarily because they're not going to go the right way to go. But they are starting to take over the decision-making. We're starting to move up into that top right quadrant in Todd Little's talk. And with the code I'm starting to get great names and illegibility is fading and bugs are starting to go down. We're starting to see a number of early wins. And when I'm working with the team we actually, these are the things that I put measures around. These are the KPIs for the transition. And by two weeks in, we're seeing notable changes. Not going to talk specifically about the initial practice. We'll get to do that more later. But there tends to be a consistent set. Well mostly. And the key thing to think about here is I don't have like refactoring or TDD on here. Refactoring is my current model. I have 14 different practices. TDD, I have seven different TDD levels. And so the levels that I'm going at are a very specific goal. The ability to refactor locally, right? You don't understand units. You don't refactor to units. You don't code in units yet. That's for later. But the ability to start making local changes and when I want to execute a change within a method do that via refactoring rather than many rewrites. Do that in the way that doesn't generate bugs rather than the way that might. So that's, again, chunks. There will be a bunch of different chunks and a bunch of different practices. That initial set is where I start a team off at the beginning. This talks towards the next two years. So if you want to, you can go look at my GitHub there. And if you've done a bunch of XP or the like, I invite you to contribute and send me pull requests. This is my current best understanding of all of the various practices and their dependencies that you run into over the first couple of years. I'm not going to talk about it in this presentation because there are like a hundred of them. But people go through very consistent stages. I see teams that are commonly expressing a certain capability and a certain way of working and they stay stable at that for a little while. And then there's a very over a short duration move to another consistent characteristic state. And those characteristic states are these stages of practice. That stage is a practice diagram is great for experts to talk about how you might do a transition and if you happen to have someone who's been doing agile, especially with the technical practices for five or 10 years, then that's probably all you need. But it's also good to have more simplified common paths through that. So this is a common path. It's one possible path through that whole mechanism sort of summarizes the things together that come together. And you see, we start there with at the top left, prepare for the transition. That's create the teams, right? And then own your destiny and stop digging deeper. So those were the first couple of things that we talked about. And this is sort of a timeline of how things progress. Find typically teams can do a transition to tech first agile in about three-ish months. They've learned to pretty much do all of the practices in a pretty reasonable manner. And their productivity has come back almost or about to where it was when they started. They pay an investment for the first couple of months. They get back to about normal at three months. And six-ish months is where they're starting to see value out of it. Where your productivity has gone above where it was when you started. Six months is also about the time where you can start paying off the technical debt. And so typically your next 18 months to two years are dominated by the people have most of the rough skills, but they don't have all of the context, or they aren't able to apply refactoring in all 1,000 different ways. And the code doesn't reflect the skills that people have. So it takes a couple of years to refactor all the code to match and for the people to develop all the different variations on how to apply their skill. And then once you get to that 18 months, two years sort of a timeline, that's when you can start doing the leveraging sorts of things. Testing and production and continuous delivery and all sorts of happy field measure learning sorts of things. So my focus is mostly on the first couple of years and really a lot of it on those first like six months where you can get most of the technical capabilities and from then it's nuance and applying it in a bunch of little details. Too long to read. Experimentation is fundamentally limited by risk. Risk is determined by errors and errors are caused by working too hard. So your goal is to not have to work as hard. So make one simple change, do it fluently. Be able to do one small easy change that will make it easier to work and do that in a way that doesn't require effort that you can do it passively. And then do that again and again and again for a couple decades. So thank you. I've enjoyed the talk and hopefully you've gotten some useful stuff out of it. And I am open for questions and conversations throughout the entire conference. Also a little plug, tomorrow I'm going to be talking about what happens at two years and beyond that.