 Kind of in the theme of this conference, you've heard a lot of people talking about unicorn. Gene Timms talked about unicorns and horses. And I think I'm going to tell you a story. A lot of the unicorns started small as brainly software companies and grew up and got big very quickly because they had the leading edge capabilities and how they develop. Very few horses have turned into unicorns. I'm going to try to tell you about a story about a very large horse that created a reasonably large bump on its head. I'm not sure I go all the way to unicorn, but it's a process and it's there. It's about a four-year journey. And it was such an amazing transformation that I felt like we had to that the organization taught me about software development. We felt like we had to capture the story and document it for other people to share. It's very short. It's very easy to read. It's not very technical. It's intended as a story that you can hand out and get people excited and enthusiastic about starting their own journey. And it has documented business results that aren't there very many places in the industry. So it's easy to create excitement, hopefully to get other people started on their own journey and get going. So that's what it is. This is about a 45-minute pitch normally. So since a lot of this stuff is in the book, I'm going to focus about 10 or 15 minutes on the transformation in the business results at HP. And then what I'm going to talk a lot about is the difference in a paradigm for thinking about how do you transform a large organization, which I think is very different than what is out there in the industry today. And it's a lot of learnings from the School of Hard Knocks. We got the bump on the horse's forehead from bumping our heads into a lot of things. And hopefully we can share those learnings and experiences so that you can learn and evolve from that and step off of that. The LaserJet printers is a very large organization of 400 engineers all around the world. It's a pretty complex code. It's embedded and it's got a very large processor similar to what a PC has on it to put all the dots on the page. It has several different processors in it and it's a very complex custom ASIC embedded firmware. It goes on the network. So you've got all the security requirements of a PC when you start scanning and sending stuff out. So it's a pretty complex system, complex features, very large code base. In 2008, we were really struggling with lengthy build test integration cycles and our products were lagging the competition. And marketing had gotten to the point where they'd about given up on asking for new features and we really couldn't get much out the door. Our costs were out of control. They'd been growing dramatically. And in the 2008 downturn, we couldn't afford to do that. And we really couldn't even add resources fast enough. 80 to 90% of all of our resources were just porting the code to the new printers and trying to get those shipped out. So we, marketing had given up on asking for new features because we couldn't get there. And so we'd start a new release cycle, give us the one endless and they go, okay, when to see you me? Because you guys aren't getting anything. It was just because we were struggling so much just to keep the code transferred over and keep going on different things. And so we went in and we sort of said, okay, we've been trying to spend our way out of the problem. That's not working. We need to fundamentally engineer a different solution. So we went through and we changed a lot. And I would say that my biggest learning through now going through my second journey is 20 to 30% of this is about technology and how to make it happen. And the major portion of it is about organizational change management. And you've got to treat your organizational change management as a very precious commodity. And you need to think about ways that you can build it into the system to reinforce behaviors so that you don't have to waste your precious resources, cheerleading, getting enthusiasm and doing that sort of piece. But you need to do a lot of that because you're driving change into a large organization. We started with, we used to have our code that would have if def statements in the spring of 04, if product A do this, if product B do that, if product C. And then we'd create a code branch for that and then we'd go into the next release window because that one hadn't gotten stable in a release and we'd have another release cycle. If product F do this, if product G do that, if product H. And we ended up creating a lot of that in there. What we did is, and this was a vision I created from the business perspective is we need to do one branch of code and we need to have that work for every product and we need to have that work for both the current products are in the field and all the future products. And for the longest time, when we're doing this rearchitecture the engineers would ignore me. I'd walk down the hall and they're like, don't look at him, he's crazy, he doesn't know what he's talking about. And then one day I came out and said, no, no, I think we've got a solution. We'll runtime configure it. We'll put the product definition out into HTML code and we'll have the code call it everywhere so I get a definition of a new product and all of a sudden I can turn in on a new product quick and easy and I can release it, a runtime configure. So that is products that are small desktop printers, two very large copiers that have digital sending, that have scanners that are on MIPS processors or on ARM processors and all those different things. It's one common code base that's tested automatically on ongoing bases in that way. And then when it's on the device that it's intended to at runtime configures for that device, picks the processor, picks the scanner, picks the paper sizes, picks all that sort of things from the HTML file, runtime configures and runs it that way. Fundamentally huge architectural change for how you do it, how do you approach it, but it enabled it and enabled it such that adding a new product onto our plans was not a major cost driver. And so where before, anytime we added a new product it was a major cost driver, all of a sudden it wasn't now. Continuous integration and test automation, we invested heavily in that. I will say that writing good test automation is harder than writing good code and requires better and stronger skills and a little bit of a devious personality to go with it because you're trying to figure out how to break things. And continuous integration is good but without a really robust test automation system you're capable of building a very large pile of junk very quickly. And I think you don't know that you've ever done an automated test and you don't know whether you have a good architecture or strategy or anything for that until you stand it up in front of the development organization and say you cannot check in code if this test does not pass. And you are going to get very quick feedback as an automated test developer if you create a crappy test and you stood up in front of Dev and you said you can't do your job and you can't figure it out. And if you start down the path of test automation when you get your first few before you write a bunch of automation stand it up in a CI environment and see if it stands the test of time. Yeah, full test automation. We went through a process of sprints. Yeah, I call this a large scale transformation to Agile. I would say for the first year and a half I had a program manager who'd read some on Agile and was doing that. I just thought we were doing common sense. I didn't realize we were doing Agile and we probably didn't start the way most people did and we couldn't afford the consulting and I had to drop my cost pretty dramatically so I couldn't afford that and we're in the middle of a rearchitecture so I could not spend a lot of time reading and I was up a lot late at night trying to drive this stuff so it was that. But we started with the process of every month writing down what objectives we thought we could do. And what I'm showing you is the results of three and a half years of monthly investments to try to figure out how to get better and how to improve and how to get this done. We never went to the CFO or anybody and sold a big Agile transformation. We never did a big initiative. We never did a big thing. We took it month by month by month and we got about three years into it and looked back and went, wow, this is dramatic. We ought to document what we learned and what evolved here and basically what's in the book is a documentation with the organization taught me over three and a half years of month by month trying to figure out how to get better. We had consistent development environments integrated tools. So through all those changes, what we ended up with is a breakthrough capacity for development in terms of whether it was a new customer capability or a defect fix, we were able to process a huge amount of code. So we had 400 developers in India and Brazil and California and Idaho and in Oregon spread around the world working on 10 million lines of code in one repository of Git doing real-time commitments with a 75 to 100 lines of code terminal a day with about 15,000 hours of tests running automatically against that with about a 90% pass rate on an ongoing basis with that. And then all of a sudden that code was certified and deployable across a large range of products. So that was it was an architectural change. It was a big investment, but it completely transformed our business and we got to the point where our cycle time drivers had changed significantly. So if you look at the time to feedback and a lot of things that you've heard here and the transition from a mainframe, those cycle times changed dramatically. Our cost drivers changed them radically. So if we set off on our vision, our vision was that we wanted to no longer be the bottleneck for the business. The LaserJet firmware had been the bottleneck for the business for two decades. It would have been longer, but it started about two decades ago. I mean, the business could not add another product. They could not add a capability. They could not do a thing without going through the largest constraint in the business was the ability for firmware to get their job done and their portion of the product. And so it had been there. And we got it to the point where adding another product was no longer a cost driver and we freed up 40% of our capacity for innovation. And we dropped our cost fairly significantly. So if you look at it, our costs were out of control. We couldn't add enough resources. We had lengthy build cycles. We had unleashed what we call the Venice chart, which is the ability to add products to your plans going forward. We dramatically reduced our costs and the cost per doing a program went down dramatically. And it took a re-engineering of the whole thing from a ground up and a focus on that. And we didn't set off to do agile. We went off to transform our business in this way and we took tools and techniques from the agile toolbox to address that and figure out how to improve. And I would say we ended up with a fundamentally different approach to doing this than anybody had considered or that I've seen going on in the industry. And I think what happened is most people who started agile started it in small businesses. And when they figured out how to do it in larger business, they said, what works in small businesses scrum? So let's start with scrum. And if you look at the scalable, the eligible framework or any of those sort of things, you start with scrum teams and you talk to people and they say, how many scrum teams do I have and how do you build up from that? And then once I've got a lot of those teams going, then how do I coordinate, do scrums and scrums and pull that together and manage that as a whole? I would say because we didn't know any better, we went off on a path to what I would call making enterprise agile, which is we looked at the agile principles and we figured out what does that mean at the enterprise level? And we approached it that way. And we did what we did based on what worked and what didn't work and we picked those things along the way and we ended up sort of with some fairly significant business results. What I think happens is there's too many people in the industry that think that scrum equals agile and I don't think that's the case at the enterprise level. If you diligently follow safe and you start with the small scrum teams and you build it up and you coordinate it and you get your release trains and all those things going, you will end up with a probably in a very similar place. And what I would say is start with making enterprise agile and then enable your teams. So the both will end up in the same place. I think you get a quicker ROI by focusing on making enterprise agile. And if you're not careful about how you do safe and really follow it to a in-state, you will end up where most enterprise organizations do with a water scrum fall situation. You are standing up, you are doing stories, you are doing iterations, you are doing that sort of thing but you still have long qualification in games and you're stuck with more traditional planning that has long lead times and stuff that you're committing to way on out that you can't follow through on and make happen. So what do I mean by making an enterprise agile? There's probably four things that are critical in my mind to make sure that you're doing at the enterprise level with the executive leadership team more than just an aggregate of what's going on at their small individual teams. And the first piece starts with business objectives and priorities. When you looked at what we did, the reason I know those cost drivers and the reasons I know those cycle time drivers, the reason I know all those pieces is that's what we documented in the very beginning. And we looked at those and we documented and we understood what they were and then we looked at our value proposition and said, what are we trying to do? Well, we wanted to unleash the finish chart and we wanted to create capacity for innovation. So any of those things that we were doing and spending time and resources on, so it's kind of more of an activity based accounting view was waste in the system. So we looked at those two things and we said anything that does not add to our value proposition, we either need to automate, we need to eliminate or we need to engineer out of the drivers that aren't key to the value proposition. So it was a fundamentally was a business value that took us there and got us there. And when somebody approaches me and says, hey, I want to do this large scale agile transformation, my first question would be why? What is your business driver? What are you trying to do with your business? What are you trying to accomplish? What are you trying to achieve? Because you can't do all of this thing at once and you've got to figure out where to start and why to start where you're starting and then you got to show some progress and some improvements and you got to build on that over time and you're not going to do that if you just start off without a grounding and sort of what you're trying to achieve with your business. The next step I think is once you understand that you need continuous improvement at the enterprise level. So each month we would set objectives. So think about you've got 400 plus developers, you're managing all their stories, all the work they're going to do. It doesn't really make a lot of sense to look at an aggregate of what all those small teams are doing and try to figure out how do they come together and make sense. So we would start with what are kind of enterprise objectives of what we're trying to accomplish, whether it was quality thresholds or we had a bit release that we had to get out for some new products or we had some stability issues or we had some new print engines coming in that we had to turn on to start life testing or if we had a new ASIC that we had to turn on. Those are the types of objectives that we would set at the enterprise level and we would set those and we'd agree on those and we did these monthly and part of it was the last week of the iteration we would be spending time trying to figure out how much of the last iteration did we get done and how much of it didn't we get done and going around and learning about that and then we'd take a straw dog or a draft of what we thought the objectives were for the next many milestone and then it would take a while to get those shopped around the organization and get people aligned for that and get people to believe that they could do it and then they'd come up with what they thought they could get done. Then we had this all tracked and metrics that cascaded down throughout the organization from myself over the organization to my next level of management, to my next level of management and these were real-time online and I could track and figure out what was going on which was extremely valuable. From that point on once we'd set those objectives and we had that strategic direction my job was an investigative reporter. A lot of times people go to Agile and say well now wait a minute, now we don't need managers, the managers are out of it and what are you gonna do? And I would say in a large enterprise you maybe there's a definition between leaders and managers but you certainly need leaders and the leaders need to set the objectives, they need to set the directions and then they need to interrogate the organization to try to understand what's working and what's not working because people set off at the beginning of the month thinking they could get this done, they wanted to get it done, they felt like it was important and for some reason something happened such that they weren't able to accomplish that. My job was then 45 minutes, I didn't have a scrum of scrum or any status meetings, within 45 minutes of looking at the metrics every morning I could tell you that Matt broke all the fax tests last night at 11 o'clock with his check-in or that Aditya's features that he committed to he's not getting them through at the rate that he was going and I could monitor that and then what I would do is not go beat up people for not getting it done, so Matt what's going on? God we thought we were gonna get there and it doesn't seem to be coming together, what's changed? What's different? What's going along? And then you would take that information and you would decide what you're going to do next because what would happen is typically we'd get about 80% of what we set off to do and an iteration done and actually this is color coded, the ones that are orange are things that we didn't quite get done in this iteration and sometimes those would show up as the top priorities in the next iteration. More frequently it was what we learned about what was getting in people's way that we went and discovered and learned about that we put as our top priorities because if we could remove those roadblocks and help people become successful then we could end up getting more done and be more productive and get further down the list next time. So it was an aggregate of doing that month by month on an ongoing basis and continuing to learn and evolve from the organization that got us to the business results and the transformation that was there and I think I don't hear that talked enough about when I hear people talk about large scale enterprise sort of transformations. The other piece which is going to be straightforward to this organization is that a lot of what you're trying to do with your CI, CD, continuous deployment infrastructure is you're trying to reduce the cycle time in a large organization if you're doing quarterly releases or monthly releases and you're testing at those cycles or the end game. What you're trying to do is over a period of time you're trying to find the person who created the offending code. Everybody know their top triage person? Right, that's the person whose job it is to go look through logs, figure out what's going on and try to figure out the person that broke the code and they continue to go through and they look and they finally get down to the okay Matt it looks like six weeks ago on a Tuesday you checked in some code that broke all the fax test. You know what you're doing six weeks ago? Yeah, to what you're probably going to say I think it was a ditty, he was in the code. I don't think it was me. I mean does anybody remember what they were doing six weeks ago? Okay if you're writing code at 10 o'clock this morning and I came by at one o'clock and told you exactly what was broken and I sent you a zip file that had everything you needed to do to reproduce that on your desktop do you think you're going to become a better programmer? Everybody wants to do a good job everybody's trying to do the best job they can if you can't provide them that rapid feedback real time in an efficient manner how do you expect people to get better? So when you're doing that a lot of what you need to think about with your CI, CD infrastructure at the enterprise level is how do you build this up? Where do you turn a build red? The tests are hard to do and green builds is not really a process I almost call it a religion you need to believe in it you need to commit to it and it needs to be on trunk and everybody needs to work off trunk and I will tell you to an engineer until you've worked in this type of environment with large scale automated testing continuous integration with a lot of that in place you will get an argument that well wait a minute I got this big hard complex thing I'm gonna have to do something different or special I will tell you after you've lived in an environment like this to an engineer they will tell you I can't imagine how I could work in a different environment I had several people leave HP and call me out and goes oh my god you can't believe what they're doing in my new company I don't even know what I'm doing I feel so at risk I can't do anything done I don't it's so unproductive it's like we're not accomplishing anything I can't believe it but it's a huge organizational shift and people will want to do well no I need this feature branch I need to hold on to this and it's stable and it's just it's a big shift and then if you look at having a really large enterprise system you'll think of Macy's as a company with a whole bunch of stuff that's been around for an extremely long period of time from warehouses to inventory systems to credit to all those other pieces you're gonna have parts of your organization that are still on mainframes with COBOL that are executing and running a lot of what's going on in the world and you're gonna have parts of your organization that are very Java centric agile sort of integrated with a more modern approach to some of the tool sets so how do you put that together on an ongoing basis and I hear a lot of people say I'm doing CI but they're doing it on their component in their place they haven't taken the idea of doing continuous integration and doing what Jess talks about which is taking as operational a like of an environment as you possibly can and pushing it up as close to the developers you can get so you give them that real time feedback so how do you build this up you know clearly you're gonna start with you're gonna start with the agile component and you're gonna do unit testing on it and then this isn't building out like I thought it would sorry about that but you're gonna start by building all the agile components as many times a day as you possibly can and doing real time testing on that and giving them feedback now do I want that hooked into a mainframe that might have gone unstable for a certain period of time and have an organization and a bunch of different parts of the country try to get together and debug it that's not very efficient in terms of localizing the feedback to the individual causing the problem so you create a mock or a test simulator or an interface between the two so you can test as much of the system and then when you've got a very large enterprise system you think about how do you build that up in an organized fashion you use simulators where you have to you want to avoid them at all costs because they're hard to maintain there can be differences it's an investment but they're very valuable where you need them and then on an ongoing basis probably once a day or so you would want to take those out of the system and make sure that you oh it's not building the puzzle's supposed to come together put it together and test as an integrated system on a daily basis so that's kind of the CI CD type of piece what it means at the enterprise I think the last thing and the hardest thing for an enterprise to do is to appreciate that you really can't get a lot of accuracy in software if there is so much discovery that goes on I've managed mechanical engineers I've managed electrical engineers managed all sorts of other process engineers all sorts of different things most of those are much easier and much more methodical in terms of how do you design and structure it software is such a discovery process that it's an alien concept for most of your managers and they keep looking for a way to make software much more predictable and what they're doing is they're not appreciating yeah they're not appreciating the uncertainty of software and learning how to manage it different and it's really hard for them because everything else they're in their industry and their business gets managed a different way so it's really difficult for them to internalize that but the advantage of software is that you can change it up to the last minute or after the last minute so it's got an inherent flexibility so one of the biggest shifts in the enterprise is getting your executives to appreciate the inherent struggles with accuracy in software but the inherent advantages of it and like Judo taking the opponent's weight to your advantage and trying to figure out how to use that most effectively lots of organizations spend a lot of time trying to invest more and more and more in planning for software to try to get more accurate and what you will see is you're never gonna get all that accurate so how do you invest the least amount in planning to make the critical decision that you need to make and it's interesting I hear a lot of organizations say yeah we're really good with waterfall we've got a really good strategy and I was working with another part of the organization that was really good at that and figured it out it's like well how are we gonna do this and it's like okay we got five days worth of work you're gonna do this Monday, Tuesday, Wednesday we're gonna hand this off and we think let's do a stretch goal to get done on Friday kind of an agile approach and we'll see what we got done and what we didn't get done and adjust from that well the program manager goes yeah great but I'm a waterfall guy okay so we should be done on November the first so let's set our target and goal for the November 19th and that's how you do a waterfall plan you haven't taken the uncertainty out of the schedule or the discovery out of software you've just dealt with it by buffering for the legacy of experiences that you've had of not making targets and having that discovery and agile's more about keeping moving forward on that and so the question was do you really need the investments of what you used to get out of in terms of the accuracy of the planning or were you even really getting the accuracy that you thought you were getting previously and I would say you probably weren't you were just buffering and dealing with it in a different way so what do you do you've got to make you know we're doing laser jet printers I've got to commit to a manufacturing line what do you do how do you deal with that because your executive's a right there are decisions they need to make and how they need to go about that well you start with your long-term commitments yes you need to make a commitment needs to happen in a business that needs to happen in an enterprise why make long-term commitments with over 50% of your capacity if you take into consideration the fact that you're going to have discovery and uncertainty you're either going to plan to a completely full load and you're going to spend all your time churning and redoing your plan or you're going to make your long-term commitments with a certain amount of your capacity with the understanding that you could do more or less and then with the rest of your capacity you take shorter windows so the printers were to your capacity we had to commit and then we do initiatives by every six month windows we'd commit to a certain number of level in that and it's a quick easy analysis these were done by requirements engineers looking across the components scene where it's loading and you can see if you're initiative rank number one count on it happening if you're 12 start your grieving process if you're an eight or a nine let's watch and see how it goes and figure it out and that's you've got to convince them to go down that path but we're way over here on this curve on this side of the curve where it was a very small investment that enabled you to make the business decision that you needed to make and you weren't wasting a lot of time and energy out there and then even when you get on down into the closer iteration month by month this is a monthly and you can look at your backlog in similar process if you're at the top of the stack you can count on it happening you can see how many stories or features you're getting done on an ongoing basis and looking at it coming in and then you can look at seeing what's in your backlog and you can look at your queue and see where it is very small investment really critical that it's prioritized list and before you start working on it marketing can change that priority around but you can get a rough feel of what's coming through the system yeah so I'm about out of time I'll leave this up here just to kind of this were some of the steps that we took to get people engaged and involved it's kind of a different approach of thinking about making an enterprise agile and it's not really out there but we were able to get some pretty significant business results so hope that helps I'll be around afterwards people have questions let me know