 Okay. Thanks for the introduction, Nuresh. But I suspect you know who I am. I'm Dean Leffing. Well, I'm here to talk about the scaled agile framework. I have about an hour. I'm going to take a fairly deep dive into a few kind of technical areas and then kind of resurface at the end and talk a little bit about some of the benefits associated with the framework. I want to start with a statement of the problem. As you can tell, I'm basically old now. It's pretty hard to admit otherwise. Forty-some years in software development. And 20 years ago, frankly, we didn't think it would work this way. 20 years ago, we thought we would be sitting at incredibly powerful CAD stations, right? Stations maybe that look like this. We're going to work like that. And we were going to create wireframes and automatically create the code and have executable models and have all these higher levels of abstraction that would be suitable for the machines that folks like Gordon Moore were building us. So I blame our problem on Gordon Moore. If he hadn't doubled the power of every microprocessor every year for the last 20 years, we wouldn't have such incredible systems. And cooperating with that trend is the notion of imagination. How many here are in kind of product or program manager positions who determine what needs to be done? Can you imagine far more than the teams can actually do? Do you ever run out of imagination? No. So we have an incredible imagination. We have incredible resources. And we thought we would be working right now like this. We thought we'd be working with, you know, individuals working at workstations and dragging and dropping and executing state machines and building models that were executable. I was involved in the UML in those days creating highly specific models. But I think in reality, a lot of the times it feels more like this, right? And in a way, these folks have an advantage. They're co-located, right? We're not even co-located. So the reality is instead of dealing at these incredibly high levels of abstraction, we deal at pretty low levels of abstraction, and we deal in a world where essentially any developer or tester working on any program of any size, up to and including some of the largest programs you can imagine, I left a company last week with 3,000 people working on a single application suite. That's pretty scary. Any one of those people can basically take a system down, right? Any two people can make a misassumption and bring a system down. So what has happened is we've really been able to keep pace with our methods. I mean, ask yourself the question, have our methods kept up with the challenge that we're facing, and I think the answer is they haven't. And that's why we continue to struggle and try to build these amazing systems one line of code at a time. But before we launch into kind of the agile discussion, we have to remind ourselves of a couple things. Number one is we do have a choice, right? So if you're in an enterprise and you're thinking about an agile transformation, this is the simplest graphic I've ever been able to come up with that explains the choice. We can choose to move forward with our requirements and specifications and implementation and leave the risk to the end, do that integration and see the big bang at the end. Or with the tools and technologies we have, maybe they haven't quite kept pace, but they're a lot better than they were, right? We have unit testing for everything now. We have great high-level languages. We can do OO without even thinking about object orientation anymore. We don't even talk about it. We do it naturally. But your choice is to start building a box and delivering a box very early or deliver documents. And I'm reminded of this and I highlighted this slide because the place I was at just a week ago, I think it was a week ago, it's a pretty big company and they had a scrum team, if you will, that consisted of about 30 requirements analysts and they ran in four-week sprints. So they would run two or three sprints at a time and they would create a batch of requirements. And then they had these other agile teams that were the development teams and the development teams would then create the code and they would sprint as well. They were sprinting and they were agile and those development teams were also run by a scrum master. And then they had the test teams who were also agile teams. What's wrong with this picture, right? They've just chopped that big, the top diagram up in little bitty pieces and said, we're going to be agile now and we're going to use agile words to describe what we're doing. But agile isn't about that. It's about the ability to create a very small amount of value in an extremely short time and then to incrementally build that value over time. And the reason we do it is simple. It's simple economics. And I remember being in a debate with an enterprise, key stakeholders and some key critics where the enterprise was talking about the fact that they had increased their releases to market to four times a year up from what had been one time a year. And the critics were saying, well, of course, you could do more releases if they're smaller, right? It doesn't really matter at that point. You've accomplished nothing really of value because you've taken the big release and you've divided it into four smaller chunks. But we know different. We know that that first release is already out there and the second release is already out there and you have integral value over that period of time. So while we're waiting for the waterfall to deliver a piece, we have actual working code in the hands of our users. And even if it isn't perfect, we're getting feedback from that and we're getting the data we need to evolve it. And another interesting thing about agile development in general is the second kind of piece of economics is that the market really only wants to pay for differentiation. So at the top of this, at the left side of this curve, what you see is the value of anything unique, the value of a feature over time. And over time, features become commoditized, right? Over time, everybody, every competitor, every application, everybody in the business can do that thing and that thing becomes a very low value. So we need to strike when the iron is hot. We need to strike when it's a very early time. I usually have my iPhone. I have a timer here right now and I tell the story about buying my first iPhone. I paid $600 for that phone, which is a ridiculous amount of money. This was before there was an app store. This was before there was no GPS, there was no compass on the phone. The camera was a joke. I didn't work for those guys. I worked for some of their competitors that had awesome cameras on their phones. The camera was a joke. The kind of camera you'd buy your kids or grandkids at Disney World for underwater photography, right? And I got my phone from AT&T and in the U.S., I don't know if you followed that whole fun rollout, but I couldn't even make a phone call, right? So I'd spent a ton of money for a device that was basically a crappy phone. But it was a really cool office in a pocket, right? And so the value had changed from an 8-megapixel camera that could take video to my ability to check my calendar, get my e-mail, synchronize my contacts, and move on with my life. And on a good day, standing near enough a tower, I could make a phone call, right? So that was worth a lot to me, even though it wasn't much of a phone. A lot of people did that. A couple of 3 million people paid that kind of money for that phone. A $200 phone now on a contract in the U.S. Does anybody know where that money is, where that cash went? That 2 or 3 million people paying $400 or $500 extra for a phone. Yeah, where'd it go? Who took it? Who has the money now? Apple. They have $150 billion. When the phone price went to $200, they didn't send me any money back, right? They kept the money. So the important thing about agility is not so much how we feel about it, or some of the amazing cultural effects. Those are tangible benefits that we get a great benefit of. But the drive for agility is pretty simple. Get to market sooner. And you can get to market sooner with a high-quality product for less. Read the book, rework, or lean startup. Any of those that basically say, you know, if we can get there early and get some feedback with a high-quality product, we're going to win in that market. I want to introduce Lean and introduce the framework, but I want to start with a few kind of key thoughts here. Let's talk about agile methods. Have you ever noticed how the various methodologists seem to argue with each other? Why are they arguing with each other? Let's take a look at Scrum. I didn't invent it. I had nothing to do with it. When I read it, I realized something for the first time after all my experience with various methods. I realized what a good cross-functional software team was. Seven plus or minus two people and a product owner with content authority. That construct didn't exist before. I thought, that's brilliant. I worked in the rational unified process. We had lots of roles and responsibilities, but there was no definition of a team. That definition of a team scales. Scrum is ubiquitous. The Agile Alliance in particular has done a phenomenal job of creating an industry of people that can teach Scrum in ways that are enough alike to have a common framework, a common way of working for an Agile team and to know what an Agile team is. Isn't that a pretty cool breakthrough? As of like 2008-2009, to actually understand what an Agile team is? Let's use it. Let's leverage the shoulders of the folks that we're standing on and put that to work. Why wouldn't we? Whatever happened to extreme programming? You saw Martin Fowler up here today say, what happened to extreme programming? I actually got tipped to Agile, not for Scrum. I saw that as a lightweight but effective software project management technique. But I sat down with a couple of extreme programmers and kind of pretended to pair program. Now, this was past the day that I could actually program anything. So my pair programming was watching a real programmer do real work. And I remember the guy Dave Muirhead was talking about his code, and he wrote his code, and he put the methods in place, and then he started writing some more code around it. And it was a unit test. And I said, well, why are you doing that? Why are you writing a unit test? I said, that really adds to the code, doesn't it? And he said, yeah, but this is my story. I said, well, what's that mean? He said, well, during planning, we're not assigned work. I take responsibility. I took responsibility for this story. I have responsibility for this story. I'm not going to release this story back into the baseline unless I know it works. And I don't know it works until it's past the test case. And I thought, well, that is a pretty disciplined approach to software development. I'd never seen that on the bench before, so I got tipped that way. I wish there was still a grand battle out there between Scrum and XP, because that would mean they're both at work. They're both at work, and they're both at play. If those of you a few hours ago attended the Nokia presentation, it's actually called Here Now. And they talked about their rollout, and they talked about their kind of Scrum-first rollout. Anybody in that session? What did they say they're doing now? What did they do next? After having largely mastered Scrum at the team and program level, what are they doing? Going back to the technical practices, right? They create the quality code to begin with. Okay, well, what about this newer kit on the block? Kanban. How many here understand Kanban? Okay. What's it optimized for? Managing, working process. Limiting whip. Aligning capacity to demand. Limiting demand to match capacity. Well, what's wrong with that picture? Nothing. So, is this a zero-sum game where I learned XP, and I have to believe in that, or I learned Scrum, and words are banned from various forums because we're talking about different things? Or do we have not only the right, but the obligation to harvest the lessons learned and the knowledge gained and really the extraordinary changes that have happened over the last 10 years or so? Well, I think it's the latter. So, I think these are all good things. I don't argue with any of these people. Well, some I argue with a little bit, okay, just for the spirit, but I don't argue at all with the principles or what they're trying to accomplish. This is not a zero-sum game. This is not, I can do this, but I can't do that. I can use that word, but not that word. There are no words that you can't use in SAFE. But let's take it a step further. Those methods work exceedingly well. How many here have seen a group of ex-peers on their game? Okay, what did that look like? Was that some of the fastest, coolest code you've ever seen? How many have seen scrum teams who have that word, that Japanese word that says that knowledge and the work are all one? How many have seen scrum teams that are really on their game? Fantastic, right? Nothing like it, in my view. That's what tipped me down this line. But they don't bring the native constructs, right? Even Kent Beck might say, well, does XP scale? Well, it absolutely scales horizontally. There's no limit to how many people could do pair work. But what does a system architect or a UX person have to do with extreme programming? What does a PMO person or a program manager who has responsibility, they don't write any code. So those things scale great that way, but they don't scale up, right? So they scale the way we need them to scale first, but they don't scale up. And what's more, sometimes I wonder, I work with big companies. This is a talk, by the way, about large-scale software development. If you're a group of 20 or 30 people, you're largely co-located, and you're working with a founder or a visionary or somebody that understands what you're trying to build, you don't really need these constructs. This is not for you. You don't have to do this. I work with enterprises that have thousands of people employed. How many here work for a company that has a thousand developers? Leave your hand up if you believe that currently it's actually pretty hard to write good code and get it to market in that company. More hands went up, not down. It gets exceedingly difficult. Are those folks that work for that... Shout out the name of a big company. Just tell me a big company name, anybody. Come on, I know there's... Give me your hand. That means you work for the company. Just give me the name of a company. Pardon? General Electric. The software development in GE, the software developers in GE and GE Healthcare, I know, are agile. Don't they deserve the same empowerment, the same decision-making authority, the same enjoyment of life that everybody on a Scrum team does? Is there something about GE that means you can't do that? Well, I don't think so. We have more than an opportunity. I think we have an obligation to bring some of these methods across and take them into larger enterprises and help those enterprises succeed as well. How do you do that? I saw Martin Fowler's talk this morning. I have tremendous respect for him. I read most of his stuff. He's a real thought leader in this area. And he said, you know, if you have a couple of arrows in your process, you're kind of already headed down the wrong path. I'm not sure I agree. I take all the arrows out of safe. I didn't have time to do that today. But you do have a choice, just like you have a choice between waterfall and non-waterfall. You have a choice to start with a blank slate. Okay? And if you're a small team like Spotify, starting off with a few agile teams, they're like Salesforce eight or nine years ago when they were 80 or 50 or 80 people, you do have a choice. You can grow that organically and you can figure out your path. But if you're a larger enterprise, wouldn't it be interesting if you're a small team? Scrum works in one team. We kind of assume it works in a second team. Well, what patterns have been proven in the industry? Well, many. You heard the guys from Nokia talking about release trains. Well, it's a label. It's a metaphor for an agile program. It's nothing more or nothing less than a program that operates in an agile manner. So over the last five or six years, I and the people I've been working with, including those guys that were on stage, we're looking for things that worked well. And I was fortunate because I was a consultant. And here's the way a consultant works. In order to build yourself a career as a consultant, for those of you who want to go down that path, you have to start out by knowing one thing. Right? And it's got to be pretty precise. But then you take that one thing to somebody who needs to know that one thing, and I'll use you as my foil here and say, I know this one thing. What are you doing well in your company? And every company has an answer. We think we're doing this pretty well, and we've learned one thing, I've learned another thing, I've learned another. So what we've done is really harvest and watch companies that have agile, agile at scale and agile at the team level, grow and prosper, guide and learn various patterns. And the patterns may or may not work in your environment, but I suspect they will because they're based upon a value system. So what's the value system in SAFE? Well, number one, it's code quality because we're talking about scale. I suggest that it's a lot harder to build a high quality system that has 1,000 people contributing to it than one that has 50 people contributing to it. And the errors and assumptions and the buffer overruns and the uninitialized variables and the lack of integration and the lack of communication and the test that I thought actually passed once but was never refactored, it all adds up. So we get this cascading probabilistic effect that if anything is wrong anywhere in the system, it's going to get worse and worse and worse and not better and better. So we focus on code quality. So if you're interested in SAFE and SAFE is free, by the way, it's publicly available, that's a website. You can go click on things and find things. And if it doesn't make any sense, stop reading it. But if it does make sense, continue to read. And judge for yourself whether or not you think this thing is going to work. You can't scale crappy code. Item number two on the list is program execution. How many here are involved in large software programs? Keep your hand up if they're going really well. Six lucky people in the room, right? We do not know how to execute large software programs. Where would we have learned it? Did we learn it in school? No. Did we learn it in the startup that had 75 or 100 people? No. Where are we learning how to build really large software programs? In really large software programs. Every one of which is different. So we're all in this massive on-the-job training, right? So consequently, getting programs to execute as well as a team is our goal. So program execution is a key element. Alignment. Everybody thinks everybody else isn't aligned. Right? Ten teams that are not super proficient but are reasonably competent and somewhat conscientious that agree on what they're building while outperforming the market ten stellar teams each thinking they're building a different thing. And when we align, we don't just I'll be an executive. I've been an executive and a developer. I've been an executive longer than a developer. So maybe I've started to lose some of my wits, okay? Been on that side too long. As an executive, we look at the developers and when they're not aligned, they're building different things. And as developers, we look at our executives and say those people aren't aligned, they're telling us to build different things. So we have to align both halves, right? We have to make sure that we're aligned to the mission of the business and we actually use some of our tools like release planning, this kind of massive face-to-face release planning to get alignment on the other side. The fourth bullet there is a proxy for trust. The scaled ads or framework are not different than Agile. It's not orthogonal to Agile. It depends on Agile. It is fully and completely and 100% dependent upon the fact the good Agile teams can build high-quality code in a time box. The values of the manifesto, we start with that in our rollout. And one of those is trust, right? Build your projects around motivated individuals and trust them to get the job done. Well, we can't build trust into a framework. We can't. That's a personal relationship. That's a sense that I'll know what you'll do when push comes to shove. But that's a personal thing. But we can build transparency. And transparency helps build trust. Transparency allows you to make mistakes and admit it. To have a poor sprint and have your boss go, ooh, that had to hurt. What did you learn from that? Transparency should allow us to start a program, get into it, and decide not to do it. And not to put the people who are on the program in jeopardy of a career limiting move because we canceled their program. If this program is going poorly and the team reports in that this is a poor program and we should abandon ship, we should congratulate those people. Not put them in the penalty box for the fact that this program struggled. So we need all of those things. But we do have a bit of a challenge. And the challenge is that as soon as you leave the bounds of the team, as soon as you leave the hall with a wall of truth and that continuous integration reports in that and you go upstairs anywhere, you go talk to the system architect or a product manager, a business owner, or anybody, an engineering manager or whatever, they don't write code. You go talk to the PMO and say, we want to do scrum. What do they say? Do they care? You can do whatever you want so long as it continues to meet our requirements. So I had the good luck to be raised in some ways in lean and manufacturing. I went to Goldrath School in 1986 and learned the theory of constraints. And by the way, the theory of constraints is still out there. We don't talk about it anymore, but it's working. Theory of constraints is in your environment. There is a bottleneck right now and all the investment that you're making, not on the bottleneck, is basically largely wasted. Okay, that's true. But anyway, we needed a broader surface area because for me, that was lean. And then as we thought about, you know, a move forward to this kind of this next generation of software practice and software processes, we find ourselves with three really, really cool bodies of thought. Solving a big problem. No one knows how to build really large software systems effectively. Our results aren't good. We build them, we get a good result, but don't you always kind of feel bad at the end, right? We just shipped a thing that nobody has ever shipped, a combine like the world has never seen. A new application, a new website, and yet we go home and we know the phone's going to ring. It's buggy. And has anybody ever come up to you and said, not only did you do it, but that's everything we wanted in the application right on time? Have you ever gotten that feedback? What feedback do you get? It's never enough, right? It's never enough and it's never high enough quality. So if we're going to solve that problem, we should have some pools of thought. We have agile, we have lean system thinking. I'm going to talk briefly about principles of product development flow, and then we apply that stuff and see what we come out with. So let's look at our metaphor for this thinking process. Let's look at this house of lean. I'm just going to talk about two or three of these. I'm going to talk about the ones in the middle. I'm going to talk about the goal. I'm going to talk about product development flow and I'm going to talk about leadership, but I'm going to end with leadership in the model. We're dependent upon this. There was somebody recently attended a class and this was a pretty renowned Agilist and he had some criticisms of what he'd learned there and he said, why are you so defensive of current management? I don't think we are defensive of current management, but I do think current management is actually present, right? They're there. So are they leaving so we can be more agile? They're going to stop it? Are they going to lead it? Right? The latter course is the one we went ahead down the path. It's going to take us a little while to get there. So there are a lot of interesting discussions about what agile is. Agile with a big A and agile with a little A. Lean has, I think, a simpler paradigm, a simpler goal. Sustainably shortest lead time. Period. Not period. Best quality and value to people in society. This is kind of the well understood description of Lean. Sustainably shortest lead time. Not bursts of high releases, followed by burnout and massive turnover. Not high turnover in general because that is the sustainably fastest lean time. And we have some hints from some of the best thought leaders in the market all the way back to Taichi Ono the godfather of Lean who said this isn't so hard how to go faster, right? Figure out what it takes to get from idea, concept to cash. Measure the time, eliminate the waste, and you'll go faster. Well, there's a secret in software development which our waste are mostly not rework or defects. Our waste are mostly delays. And I was attended, Al Shalloway talked at Staples about a year and a half ago. I think that's where Lisa was at the last time we were sitting together and he put up a position and he said, you know what? I believe that every time that most software problems exhibit themselves as delays. So raise your hands if you're in a large program right now a large program that's struggling. Okay? Keep them up if you're delivering early. We know what the problem is. The problem is delays. Most software problems exhibit themselves as a delay. And value stream analysis which was mentioned earlier today a couple of times is the way to get at that. And Mary Popp and Dick I think said it even cuter, right? We just need to figure out a way to deliver software so fast that our customers don't have the time to change their minds. Did they really change their mind? Or is it the case that more likely the market changed in the meantime? And it's probably the latter of the case. I want to take you on a short sideways journey before I bring you back. In 2009, Don Reinertson published his second book in his kind of series on flow called Principles of Product Development Flow. I'm an author. You probably know that. I like it when you read my books. Well, I actually like it when you buy my books. If you read them, that's a second order concern, really. And I would encourage you to do that. I write them for a reason. I'm going to give you here today in terms of what book to read would be Reinertson's book, Principles of Product Development Flow. Anybody here read it? Pretty easy read, right guys? Oh, yeah. Tough book. Don is certainly one of my heroes. He's working on a book. I'm not sure who's going to title, but it's going to be Principles of Product Development Flow you can understand. But there are eight principles here, and I'm only going to highlight a couple, and they make us think about software development differently. And just a few vignettes from there, just drill deep for just a second. Reducing batch sizes. We don't even think about batch sizes. What's a batch size? What's a batch in software? Where would I see a batch? Somebody give me an idea of a batch. A batch of requirements. Let's just take that one. That's a good batch. Let's take a batch of requirements. Here, and look at this chart from POP&D. You can talk about that a little bit. Now, when we put this batch of requirements, small, medium, or large batch into a system that's composed of software people writing code, what utilizations do we typically run our software teams at, individuals? What percentage allocation are they assigned to work? 100. And maybe 110, pretending like there's more time than that. What this chart says is that if I have low utilizations, then my batch size doesn't make too much difference because I have the capacity to flex. But as my utilizations get higher and the batch size increases, I start to have extremely high variability in outcomes. Put a lot of cars on the freeway and the freeway is highly utilized. You might just go fine or you might have one flat tire and the whole freeway comes to a halt. It's just the nature of systems. We are building systems and we're also a system that builds them. Let's take that requirements batch right now and let's think about waterfall from this perspective of reducing batch size. Here's a big batch of requirements that I'm going to put into a system of people running at 100% utilization. What does this chart say I'm going to yield in terms of cycle time? Extremely high variability. High and highly variable. Have we experienced putting large batches of software requirements on top of busy people and getting extremely variable outcome? Absolutely. We live that life every day. So do we just hire people that are fundamentally brain damaged and aren't capable of actually delivering stuff on time across in India in Serbia in Argentina and the US or have we built systems that trap people in a really awkward spot? I think it's a ladder. I think we've built systems that are actually quite predictable. It's predictable that a really big batch in a big system is going to go slow. Here's a... We'd like to talk about lean thinking manager teachers. That's what we try to teach. Before we teach safe, we try to teach lean thinking. Here's a lean thinking thought experiment 101. If you approach a service with a need for service and the service is running at 100% utilization, what is your wait time? The service is running at 100% utilization and you need service. What's your wait time? It's infinite. Doesn't it seem like sometimes when we approach our software teams it's an infinite wait time? Because they're running at 100% utilization. There is no capacity for new work. One other thought. I never thought about software queues until I read Reinerston's work and now I see him every day. I see long backlogs that are committed. Okay? If your team has a long backlog and that backlog is committed it acts like a queue. It's not necessarily a first in, first out queue it's a queue. I have to shift this stuff. I've made that commitment. The longer the backlog is the slower your team is. So if you have a crack team like the best team you've ever assembled in the history of your software development experience and they have a really long backlog, they are by definition slow. Why are they slow? Because there's a lot of stuff in line. Here's their backlog. My new thing takes this time and you can see Little's law which basically is a proof of the theory that says the average wait time is equal to the length of the queue divided by the average processing rate. So when you see those queues when you walk out and try to get a cookie or get a beer and you start thinking about well why don't they have, why don't they pull the table out so we could service the queue from the other side and cut the queues in half, you're going to start to think about a lean thinking manager teacher and then you can look at your software the same way. Whip constraints. Largely counter-intuitive to many who manage us. Doesn't it seem like the more stuff you put in for work, the more stuff you'd get out? Doesn't it seem like I just shoved a little bit more in the front, the pressure and the system would go up? I did this talk one time and a guy said I just put in a water feature and he's going, I couldn't figure out what was going on. He said I hooked up the pump, the pump was really great and there's no water coming out the end and the pump is sitting there, it's running, it's like crazy. There's water in the input. What's going on? He couldn't figure it out. So he went out with a drilling and then he started drilling holes and it started squirty and then he watched the end of the tube and the more holes that he drilled the more water came out the end. So the pump was cavitating. There was no, they had so much pressure in the system that nothing could actually leave it. Our software systems work the same way. We think about work in process constraints you think about visualizing work. I'm reminded of this big visual radiation radiator, kind of con bond or scrum board or whatever you want to call it. And I found this team, I was helping this team serious work, people had invested a lot of money, nothing was coming out of this team and they had the board but they didn't have the dates on top and they didn't have the rope and the rope was actually a set of headphones that were broken that I used. So when I got there I said how are you guys doing? I said we're doing great. There's a con bond board so I went up and said what's today? It's Wednesday put the labels up there and took the headphones up there and nailed them up and now I have a question for you, how is this team doing? What do you think? They're going to land the sprint? Looking good? Looking good? Not looking good at all, right? Not linear flow, they only have a couple days they have one story and accepted. Here's the thought experiment. What if somebody came in and said ladies and gentlemen, boys and girls from now on we're not going to have more than three stories in development and at any one time. We're going to impose an arbitrary whip limit. Prior to that whip limit if a developer had just finished story six what would the developer do? What do developers like to do? They like to code stuff so what would he or she do? Go get another story, right? If there's a whip limit what does that developer do when they finish story six? They have to go help somebody test. Just flow through the system go up. Is a developer as efficient at running HP quality center as a tester? Not necessarily. But does throughput go up? Am I optimizing for throughput through the team? Or am I optimized for individual developers' efficiency? I'm optimizing for throughput. So whip limits is one of those things that you get it and it starts changing behavior. It starts making you think differently about software development. Now let's take a look at the framework and the time we have remaining. I was fortunate in 2000-2001 to have a task assignment to go into an enterprise that was a bunch of folks that used to work for me at Rational Software and they had joined a startup and they weren't really operating very productively and the CEO called me in to help coach the team. I had learned new things. I had learned XP and Scrum. I put my skills to work my newfound skills to work with this team and within about six or eight weeks the team was re-engaged and delivering value. Here's what's interesting. This was the same team I had managed before in another environment. So by a simple change of process by implementing kind of team level agile that team was able to get on its game and their pride came back their sense of pride came back and they started showing up, the VP started showing up at the board meeting and saying well we got that release out on time and that's awesome. So nothing beats an agile team. Never seen anything like it. Not messing with that formula. That 7 plus or minus 2 with good solid technical skills works great. But we need to do some things. We need to align them and we love user stories because they start this process of aligning the way the team works to the way their user gets value. Now as the system gets bigger those stories get funkier and funkier pretty soon I'm just building a web service or I'm building a business rules algorithm or something like that or I'm parsing a web page looking for entities and I'm having a hard time finding my user. But maybe my user is another system or maybe my user is a GPS device on a tractor but the user story still works great and we love it. I don't know if you know about my history but I've written a lot of words about software requirements and sold a ton of books on the topic. I wish I would have invented user stories. It really aced me on that. Jeffries or whoever came up with that or I think maybe it was Ron, I'm not sure. He had a really cool invention. And by the way a user story is a cool thing for another reason. It's an object. It's a small object of value. It's a small object of functionality and our requirements were never that, right? They were stories and they were pages but they were never really objects and now all of a sudden we have kind of an object approach I can measure a user story going through the system. If you try to scale crappy code you get really big crappy systems that are extremely hard to debug. So we double down on our rollouts and we want to first talk about these basic practices. Now we have one here that doesn't occur in any earlier kind of XP derived work. We talk about architecture quite a bit. Why? Because your enterprises are building really big systems and they have to hang together so it's a really big paradigm. Continuous integration test first, refactor. We call it pair work. Pair work is extremely valuable. Pair programming is a bridge too far for many people. Some people just can't stand the idea of two people with one keyboard or two people with one keyboard just doesn't make sense to them and also there's a lot of cultural issues. So we don't say you have to do that we just encourage it because four eyes are better than two for sure. But let's scale a little bit. Let's move up the stack. Let's talk about what it takes now to make a system out of all of these teams. Those great agile teams. They're coached, they're working, they're largely on their game. But what Deming notes is that systems are really very interesting. Systems by definition consist of components. That's what makes a system a system. There are various parts that can be replaced by other parts that still exhibit the same behavior. And there are two systems at work here. There's the organizational system that you're using and there's the subject system which is the software you're building. They'll both behave the same way. So an agile team will locally optimize. They're inspected adapt will do that. Can't blame them for that. They should. But we need to optimize a little differently. We need to optimize for the system. So the secret to building system is cooperation. Right? There's last talk if you saved those last one. The big message there was communication. Right? Communication and collaboration well those are other words for cooperation. So that's the secret. So what do we need to do? Well, we build these programs but I want to talk about the program from a slightly different perspective here before I look at the roles. I'm not even looking at the roles. What does an agile team do when it sprints as grum team? They plan together. They execute together. They build working software in a time box. Some number of entities called stories. They inspect and adapt together. They have a content authority. A person who can make a decision for the team. That's the product owner. And they have a scrum master who is a servant leader for the team. Right? The program works exactly the same way. Right? We plan together. And that can be a trick because it might be many people involved in planning. We commit together and we commit to a set of PSI objectives. Which live right there. What the teams agree that they can do it. They execute together. And they inspect and adapt together. And they're harmonized by a single program backlog. A backlog is another cool requirements thing I didn't invent. And a simple placeholder that says this is the work we're about to do. And if it's in there we're going to do it. And if it's not in there we're not going to do it. So alignment happens by is the thing in the backlog. They get it done. They get it in the backlog. And our product owner, our chief product owner here is typically product management. Maybe business analyst or program management. So we take this thing called the agile construct, the agile team and we take it up on fractal. We just up in a notch to the next level. But when we do that we have to change a few rules. It's going to be awfully awkward if in the middle of that program one team is one week sprints and another team is sprinting and two week sprints and another team is sprinting and three week sprints because when were those sprints aligned? You also heard Martin Fowler talk about feature branches are bad and we agree. Everybody agree? Feature branch is largely bad? How many here still see feature branches all the time? Right. So they're bad and we need to get rid of them but we still have them. So given that we still have them in the process of sprint boundary so that we can make sure we can collapse those branches really quick. So if a team is running one week sprints, two week sprints and three week sprints only by accident every six weeks is that opportunity. So we say let's just align the teams now. Let's align them towards a common thing and avoid this problem that we see in agile all the time which is the teams are sprinting but the system isn't. The teams are sprinting. Their component is moving forward but the system is still largely water falling. Interim incremental stuff built but there's no steel thread through it. Right? Might have a steel thread through a single feature but not through the end to end. So the goal isn't really for the team to sprint. The goal is for the system to sprint and in order to do that we usually need some help and that's one of the discoveries. When we put these release trains together and say okay we're all going to work together we're going to have a system demo in two weeks. Somebody says well who can run the system demo? We have five different configuration system environments and five different CI environments and four different platforms and they're spread all over the globe. We've got three test labs and nobody has an Oracle license and nobody can get a copy of a load runner do load testing. So we have to resource that problem very early on in the process and go from there. But I want to make a thing clear that the big picture doesn't make really clear and by the way big picture 3.0 will make this much clear. So by the way, so if it isn't done I don't know how there's no definition of done for safe. The definition of done for safe for me is when I'm too old or senile to be able to contribute and there'll be some other people because I don't believe that you have yet figured out the very best way to develop software at scale. If you have we'll stop safe but as long as you're learning we're going to learn too. So we're at version 2.5 and 1.0 comes this fall. We'll start laying it into the framework pretty quick sometimes in a month or so you can start to see the changes. But one of the things that you can infer from big picture 2.5 that we don't like is that these big blobs these PSIs those are releaseable points. No, those are the cadence based planning points. They're really plan super increments or just this big blob here when we've planned and committed to that so we want to do what we do best we want to develop on cadence but deliver on demand. We want to separate those concerns because it's not often the case. I mean maybe you're Salesforce.com and you ship every 8 weeks after a couple sprints but maybe your net app and you ship 5 times a day or maybe your company for whom shipping every 10 weeks would blow the mind of your customer who wants to reinstall a new version of SAP some things are just too disruptive at this point in time. So we want to make sure that we separate the concerns develop on cadence and deliver on demand and then we think about this system again and we think about what holds that system together what gives it its purpose in life what is its aim and where does its aim come from. I couldn't have more respect for software developers. I've built my whole career by essentially translating for them translating from the technical speak saying things like my chief scientist didn't really mean to say that you were the stupidest user he ever could imagine what he meant to say was that he could have done a better job on that particular part of the UI make that translation and get through the meeting with my life that way and on we went and the domain expertise make no mistake about it the people that know the most about the system you're building and the domain you're in those who have to determine what the strategy of the enterprise is that's a different problem right that has to be left in the hands of the fiduciaries who are chartered to do that they're the pros and by the way they have the money right that's where the money comes from that's where our paychecks come from so they're the ones that have to make that decision we have to respect that so in say if we represent that as portfolio vision and it's something that we want to have expressed we want to know what you're thinking about what new initiatives they're going to head that way we like to think about well strategy is a thing that gets centralized but execution we can do that let us handle that tell us where we need to go give us the vision let us do the actual program execution and you see there we picked the Kanban system just as one way to express the way the large initiatives work in that model we also find the PMO raise your hand if you're a big company please or you work for one keep your hand up if you have a PMO okay, pretty unanimous they're there right so what do we do your dog doesn't hunt anymore we don't need your SDLC we're not going to attend that design review we don't do milestones we're agile we're going to build the right thing or we start to here's another question where do you think they learned how to govern waterfall development who taught them I think there's a school that they go to that there's some secret people that come in and say there should be a milestone called design complete who taught them that stuff Michael who taught them that stuff we taught them that stuff right because that's the way we were building systems so we said this is the way we need to be measured well guess what we're not building systems that way anymore but they're still measuring us that way so before we go in and bang them on the nose and say your dog doesn't hunt anymore we don't need that we've got to have answers for them and originally the very first version of the big picture I drew was an informal just kind of a sketch on the board to show a PMO what the after case looked like how funding would flow how programs would execute how agile teams would contribute to the value stream and so they could see the after case and in so doing we have to move from the three legitimate functions that they have and start describing how that can happen in an agile manner because their responsibility for strategy and investment funding hasn't gone away and if there's two or three thousand people or even a thousand or even four hundred writing software development in a company isn't it going to be helpful if they have a common way of working think about it I got four hundred people and they all call the thing they do different they call it a backlog item a user story none of the above they use t-shirt sizes for sizing they don't size they have velocity they don't call they don't call it velocity they have three-week sprints we're all doing things different how would we expect to cooperate in a world like that and then lastly the least favorite word of the agile governance I guess because it looks like government but before we throw it out and make fun of it what is governance really if a team inspects and adapts and we expect them to do that and if a program inspects and adapts and we expect them to do that don't you think we should have some feedback on our spend wouldn't you think that if you're spending one of the programs I'm working with right now spends one point seven million dollars every PSI don't you think somebody is worried about what's coming out of that and isn't that a legitimate question but if the way it's been done is funded a project at a time rather than fund a release train if the way it's been done is hey your feature is taking longer please come to the variance analysis meeting and be prepared to defend yourself then you're in a weird world you're kind of in a blame game in the middle of R&D I suggest that you probably how many of you feel like you're doing research and development in developing applications and how many of you have the research teams right beside you you don't we do our research in C2 right we invent our new things and take all the risk of that right and stride at the same time and if you get involved in discussions about I like this method I don't like this method this is a question for the group how would you measure a framework or a method what would matter there are five methodologists up here describing various frameworks what are the measures what makes one good or bad tell me something what matters I'm sorry I didn't hear it too far back from my week years fit for purpose right what matters why do we do this work to get results right so if you want to measure a framework look at the results let's just take a look at a few results Mitchell International 40 percent decrease in post release defects decrease in time to respond to customer requests that's more fun I'm not a person who starts with the cultural aspects of the cultural chains formation in the enterprise and the reason I don't start there is because it's so hard right it's like changing the company's personality there are people that are better than that than I am but what I've discovered is that if you can get teams to deliver higher value more quickly at higher quality they start having more fun they start to work so you can change the culture a team a program at a time Telstra Australia six times increase in delivery frequency 50 percent cost to deliver production John Deere been building combines and they were actually not combines been in plows since 1867 warranty expense first year of scaled agile adoption was down 50 percent year over year that's a pretty big deal I don't know if they're in if they're in Bangalore or not involved in subcontracting their view and many of your view is on the receiving end of a kind of an awkward process where in the end you're told to write this piece of code for some purpose you don't even understand anymore that's not the model with the framework the model with the framework is that everyone is on an agile team everyone deserves to understand the mission employee engagement goes up turnover goes down winning is more fun so how do you do this tell you by analogy I was involved in the 80s in some lean manufacturing transformations places where where buyers went into suppliers and helped them make their plant more lean why would a buyer invest their time and money in making a supplier more lean what's the principle at work here they get better product you're not very lean your costs are too high your quality is too low it's hurting me and here's the way it would work they would say hey we're here to help you seriously we're not even going to charge you a nickel and we want to teach you lean manufacturing and they would take the leaders and the managers aside for lean boot camp a little bit of training anybody have an idea about how much time that averaged here two few hours what do you think two weeks two to six weeks so I'm a manufacturing manager and I go to lean boot camp and on the way to lean boot camp I walk by my finished goods inventory with a sense of pride look at all this stuff three weeks later I come back look at all this stuff we haven't sold yet what were we thinking they have a lobotomy and work and process used to be an asset because I can reduce my expenses because I can relieve that cost of my labor and now it's a liability and now I want to get rid of work and process they didn't walk on to the floor and start teaching people in the manufacturing sell different ways to build product they taught the managers to teach the people to build product here's a question you are the change agents in the market that's why you're here think about your managers and your peers how much training in lean and agile have they had how much did they know about this new paradigm how many hours or days how many books have they read how many books are open on their desk not so many however they are our leaders you are our leaders you're here for that reason and the expectation 10 years ago in these transformations my first expectation to managers was that you'll be supportive of our change my second expectation was that you'll be you'll understand the change and you'll help us eliminate impediments and after about 5 years I woke up and said well, too low of expectations my expectation now is that you will lead this change and in the last major transformation I was engaged in we had an ask we asked the enterprise big company 1,000 developers worldwide in a world of hurt competing with really, really good companies particularly in China and Korea in the consumer electronics market and they said we would go down the agile path and I said okay here's the ask we've learned some lessons we've trained all the leaders and managers and we'd like 2 days not 2 weeks, 2 days, just give us 2 days and what do you think the enterprise said they're too busy too busy and you know what we said so are we then, we're not going to do it and they said okay, we're going to call that and we had then scheduled about 160 managers in 5 to 8 countries we had a 2 phase plan we were going to teach them lean and agile thinking and because we had a beefy capable agile working group, the 2nd phase we were going to come back and help them transform their shops we did the 1st phase, we executed we went around the world, my wife still remembers that trip, she was saying whatever you do, don't do that again you go to India, how long are you going to be gone as long as it's not like that other trip you're okay trained them all went back around 6 or 8 months later visited many of these people okay, we're good don't really need it, how come they knew what they needed to do right, they were trained and they said, we can do this there was no mystery or rocket science, there was no secret sauce or secret handshake in this stuff this is basic discipline of understanding the way work flows understanding the agile methods rebuilding trust in the system building transparency, we got it we can take it from here successful program company turned on its ears, I got an email just a few weeks ago from a VP there who said basically if we hadn't taken those methods to heart and if the leaders hadn't taken and executed that, we would never have survived in this marketplace but we didn't do anything, we didn't write any code, we didn't even coach the teams all we did is train the leaders so there's a difference between agile and lean agile is about the teams and gosh, we love them they do all the work they write all the code but lean is about thinking about the way the enterprise works and lean is about engaging the people that are there not some group of managers are going to come in after we fire everybody that's already there but give credit for the people that are there, you know the thing about manifesto about trust them to get the job done is there a statement in there that says and trust your management to not be completely incompetent no but we have to do that start with the assumption that these are intelligent people that are also locked in a system that's fundamentally flawed and when they see how to change the system they will and when they will you'll win that's it for me and that's the end of my pitch I'll take one question, I'm at my 60 minute time limit I respect your time box there's probably dinner out there but I would be insulted if I didn't get at least one question to answer so just give me one, somebody give me one question go middle management is always a challenge, so it is absolutely they fear right so here's the thing so one of my customers called that the permafrost right, the permafrost layer it's pretty soft the standpoint is really malleable but if you're underneath it the charges are off we take that on direct and we basically train them we show them the new model and make it very clear that there are roles for leaders in this organization when you see people start to understand lead as a way of working they start moving to the organization and become the future leaders we also make it clear that not everybody has to be on that bus because the executives have laid the direction here's the role of middle management it does get leaner but I've never yet seen a talented middle manager who gets it, leave the enterprise never seen it so just go right at it give them the tools they need, give them the training give them the confidence to say you can do this you can teach a team you can read a book you can learn about TDD you can read principles of product development flow you can become the leader they deserve so middle management is the key and while I didn't go through the list this list is for them and on the safe website right now there's an expository document about what those things are and some guidance for how to develop those people because when they understand that agile is going to fly through the system really really smoothly so thank you very much for your time on a late day and we'll see you around as well