 I'm Mike Russell, and welcome to a session on powerful development methods. Now, before you start for the exits, this is a session on business agility. It's just that the same development methods that you really learned here else-wise in the conference, the same lean and agile methods that have proven so powerful for developing systems and products, my premise I want to give you this morning, one of them, is that those same methods can prove inherently powerful in working on the system that is the organization. In other words, we use the same methods and thinking to work on the system that produces the systems and products that you're producing. And it may not have your coffee yet this morning, so they'll keep from going far enough. You may not get it again. We're going to work on the system that produces the systems, or if you're from the product side, work on the product that produces the products. Now, let me introduce another key concept to you. That is that you can probably make more of a difference than you think you can make to the organization or to your business or to whatever unit that you're a part of. Why? It's because by working on the system that produces the systems or working on the product that produces the products, if you want to think of it that way, your impact can be more powerful, can be leveraged, can be magnified because the impact will not be just on the very specific product or project that you're working on now, but will be on every single unit that's produced in the future. So every 5% improvement you might say to the organization makes a 5% improvement across all the products or projects, not just the one that you're working on now. So let's take that idea even one step further. There's a main comic strip, named Pogo for the main character who's also named Pogo, and this statement's been used many, many times, millions of times probably. We have seen the enemy and he is us. Now, what that's implying is that sometimes we're our own worst enemies. In other words, how we organize our work, how we go about our work makes things worse rather than better. So my contention to you this morning is a different one. We have seen the hero and he is us. Why? Because as Agilis or me, if not aficionados, people who know something about me and Agil, by working on that system to improve the system, you can be the hero. Now why do I use the term hero? Well, it's because it's a matter of life and death. In this case, life and death of the organization, the team, the company, the business that you're in. Life and death matter and because of how you're involved and the enormous impact you can have, you can make a difference. You can be a hero to all those people that you're around. So the good news is, a lot of people are talking about this morning you already know something about. So it's not a major learning exercise, except for the fact that we're going to take those pieces and put them together in a really different way, a really different model to think about, to be able to use them to then impact the organization. Now the bad news is, is I just used the word model, we're going to be talking about models, theories, some of that stuff. We have to back up, go to the higher level first, before we can then use them effectively. Otherwise, as with all things being systems, is that if you make a change and you don't really know why you're making a change or the system that affects you, you may end up making things worse. All right, so let's jump into it. I'm going to just give you an explanation about the start of my quest around the beginning of this. I started as a developer, as an analyst, the same as many of you have, and I'm doing estimating on projects. I'm doing a good estimate. I'm trying to think in terms of all the curves that you're emphasized, or that you're encouraged to use when you're doing estimates. This one is a curve about probabilities, about where the outcome, the idea of doing a 50-50 estimate, the idea of instead of coming in, it's most likely to come, one that's 50-50, right? I also thought in terms about the funnel, the development funnel, the cone of uncertainty, meaning that at the beginning of a project, things are more uncertain than at the end, obviously, because as you learn more and learn more, you can make better estimates. So I've worked through all that stuff. I'd come up with the best estimates I could, and I'd mark your merit on my papers and backup, and I'd give them a range along with the associated probabilities of why I thought that was going to happen. In other words, what's the risk of this happening? Was it big? Was it small? How big was that cone of uncertainty? And what do you think the answer I got back was? Or the response back? What do you normally get when you go in with a range or something like that? Just give us a number. Like, what? All this work I've been doing, I'm trying to tell you, some of the other things you say, no, just give us a number. So I thought about it, and then as I go through the estimates, if I have to give them a similar number, which one am I going to give them? Which one would you be likely to give them? The higher one, probably, right? Otherwise, I'm going to get crushed at the end. So I got the response that I'd get back to them. That move, you've got to be kidding me. You must be padding, right? You must be putting all this stuff in. I said, look, I just gave you all these estimates and I was very frustrated. And over time, as I started to work and became a team lead and running executives, I kept working on this concept, but what's the issue here? Is it an individual lack of understanding, or is the problem of doing it? Is it a problem of me and how I'm doing this? Or what is the exact issue behind this? What's causing this? What's the need cause behind all this? Or is it the fact that the system, the organization has been designed such that the normal response for those people on the business side, those other people, was to reject what I was saying. So more over time, that's the answer that I came to. It's not the fact that they're not smart, they are smart. Most people you work with are really smart. It's just that their aims, their perceptions caused them to say, just give me a similar number. The system I'm working in requires that I have a similar number for input. The financial system requires a similar number. If I put it in an orange, it'll blow up. So that's not what I need to do. So the system components that we're going to talk about in brief today, really are four parts. This is one of two models that I'm going to give you that I've come to at the top level, and these slides will be available after the comments. So you don't have to worry about discriminating. Just think about, get the concept down. Four key components here. I'm not going to give you a systems model in terms of feedback loops and all that, because by the time we get through that, it'll be the end of the session. So I'm going to give you the components here, the leverage points. One being culture, second being people, third being the overall strategy organization, and the fourth being processes and systems. The rest of what I'm about to detail is just keep in mind that there are these four spheres, every time you make a change to that system, there is the organization that you're usually going to touch on one of these. Now, the key leverage areas that you have from my perspective, and this is what we're actually going to talk more in detail about from an overview this morning's session, is one, the leadership of the organization, always the critical component, but secondly, design thinking. I'll give you a little bit of an overview about design thinking and what that means to the organization, and then thirdly, the managerial innocence, which is where you come in. All right, so let's go back to what we were talking about before. The key issue of life and death here, what we're trying to get to is for you to help your organizations to survive and thrive in the chaos and uncertainty of this today's business world, right? And so my proposal to you is that you are that life frame or that hero that's going to help. So what causes organizational death? Top level categories want a bad idea, okay? Anybody know what this is? Recognize it? That's not a poem. It's an apple poem, if you will. This is the written, right? Not exactly one great product successes of all time, but it came from a company that's known for product successes. What did they do? They took the things they learned from it and from that came the iPod, and then out of that again came the organizational system that's real IT, that's really made, right? That whole ecosystem. So a bad idea doesn't necessarily cure you. What about bad outside events? The economy? It's one of those going on right now. So let's look at things that happened during past economic periods. First is during the Great Depression in the United States and elsewhere around the world. Two companies that are now worldwide powerhouses, household names, Walt Disney, McDonald's, during the Great Depression. During the early 80's depression Microsoft started, Harlan Davidson made a huge turnaround. Electronic Arts, Adobe, not minor names, but they started them in times of bad. So it's not outside of it. So how about during the 90's recession? IBM made a big turnaround. They were dying, made a turnaround at the worst of times. Bungee started, I'm sure none of you played any of their games. They had a double crash when the iPod was actually launched from Apple. And now in the current recession, Groupon more than millions of valuation has been lost. So I mean gained. So it's not really outside events. You can overcome that. So maybe it's the execution of the issue. So what then from an execution standpoint might be some realizational problems? Well, you may have seen this. The idea is that organizations all have life cycles. They start, they start building up, they come to maturity and then eventually decline in debt. So that's the curve, right? You start going up and then you decline and die. The crisis point, B, is when you either notice at some point in time that things are going down or you know that they're going down and you gotta make a decision about what to do. So the idea here that you're using all the economics courses or the courses about business is, hey, let's change things so that we start our investing in the future when we're at the riding the crest at the top. So we start again and then take it to another higher plan, another higher plan I tell you. So we start measuring these sigmoid curves so that we not only survive now, but we continue to survive in the future. But it requires investing now for the future. That sort of idea. What typically happens? The common reality is that we get that crisis point and it's almost too late or it is too late to invest and we just go down the tubes, right? One trait goes down from the business perspective. So let's take this in a little more detail. If we take that curve it's the same as a single product life cycle. From a product perspective, we do development and if you look at the profits curve here we make an investment so the profit is going down because we're expanding, right? We're putting stuff into the product. We introduce it and now we start making sales. Well, hopefully we start making sales if it's a good idea. So sales and profit start rising. They come up, right? Grown, hit maturity, the apex, the peak of getting income, revenue, everything else and then they decline. So that's the sigmoid curve in regards to a business but it's also from a product perspective. So now if we look how to extend organization of life, the idea here is that we want to extend that peak as long as possible. We want to improve our operational methods so that we're going to get as much out of that product that cycle as possible, right? To extend that maturity lengthen it as long as possible, right? So that product is there and then just like to have the double curves is that we're going to take another product and start developing it. When we've got the revenue to do it, when we've got the margin to do it so that we can invest for the future, right? That's the theory. Again, what typically is is that we wait until two or eight, right? We don't start thinking about the next product once we introduce one or start getting the revenue and we start panicking around the line and it just goes down a little from there. And there's some other issues here. For instance, this is an overview from PMI of projects versus operations. Look at what I've highlighted here. Catalyst for change, which is projects. The whole point of doing a project is to do something different, right? I mean, if you can do the same thing, then we don't even bother starting with a project. We just do what we do. But from an operational perspective is maintain a status quo. Right away, if you're doing anything from a project perspective, we're now coming at loggerheads because I've got one team that's saying hey, let's make some changes. Let's get some things going. Let's make an impact on the organization and another team is going whoa hold your horses there. The other thing is to say we want to maximize our efficiency, get things moved out. So another conflict, projects and operations. Okay? So from a perspective also of extending the life of the company is that if I'm focusing on getting that maturity and making it longer, I'm giving a certain set of capabilities that helps me to optimize. In fact, optimization is one of the key focus points during maturity. During that peak time. Systemizing, taking everything and putting it into a system, right? And then yes, around a six-sigma getting the last ounce of profit revenue that we can out of the system. But if most of the organization is focused on extending the life of that revenue, right? All that life-driven organization those approaches don't work over in the private development side. They don't work in innovation. Some of them do, but most of them are focused totally different, right? Again, the change versus status quo. And do this what is called the rearview mirror trap. This is a quote so we've got all these forms of analytical logic to draw in the past rather than the future. So in other words it's called the rearview mirror trap because the only thing you can conceive about the future if you're using purely analytical methods is that which you've already done. So you have that, right? If you just use analysis and analytical methods of what's happened in the past then you're only looking for variations on the past. You're not looking for a big break of big innovation for the future. All right, so what that brings to the result of Paradox is that if I had these curves where I'm trying to extend my new revenue of the existing organization, but I'm also trying to introduce new things that keep me from hitting that crisis point for being able to survive in the future then that success that I've got at the top of the curve that I'm really trying to bring for later usually means I'm going to be less successful when I'm introducing something new that's going to help me succeed in the future. So on one hand I am the more successful I am at doing that revenue at maintaining the status quo means from an organization perspective not from an individual perspective necessarily but from an organizational perspective I'm going to be less successful in the very things I need to do to be successful in the future. So that's the key paradox about how the organization is set up. That's why the questions right from the development side like when I'm doing my estimates and I'm going all these points and ranges and risks and everything is it just giving me a number because it's different things, different talking. So some reasons about why the top is emphasized in other words keeping things status quo, systemizing and optimizing here's a picture from the original for a simple line the concept of the whole a simple line concept is let's keep things exactly the same, have highly specialized jobs so we do the best that we can at one thing at each point on the line. Also the famous experiments if you have any management theory about plants at GE's Hawthorne plant right the Hawthorne scientific management of time material studies about how people are doing their work how can we improve their work around the analysis of what's existing from their own perspective and financial markets the US versus the Borses here in India it's a short-term range of what results can we get now which is the emphasis on what the revenues and profits that we currently have not necessarily the future right and that pressure is on the CEOs and the rest of the organization to produce for right now. Right so here's the central paradox again in the slightly different picture we've got to use opposing views approaches and goals but we need both of them not just one of them this is not an either or it's not the same thing as me arguing with them saying but you really should take this range and they're saying no I need this point of estimate it's we really need to figure out how to work with both of them because on the development side I'm going to increase variation operation side I want to decrease variation its whole point of six signal other things to get rid of the variation because that costs you money and makes the efficiency lower I want to do change don't do change I want people on this side that are highly skilled and probably aren't going to be able to do ten different things right on that side I'm looking for people that are slotting in the whole idea of the similar line right it's now set of skills if they don't work out I find somewhere the same set of skills I'm not going to do that where you need intuition and special product development that side optimization and also reliability and stability to key roads right so it's also a different thinking approach analysis intuition and what can be right again from using getting all these terms here because these are words that you've used in different context but I'm putting them here specifically to pull out the things that you learn from the linear and agile perspective and put them in the higher model so from the product side we're thinking about what could be set intuition part and from what will be from a rational or deterministic side and what we're really looking for it should be right design the organization using both of them so we should have the profits we should have the future right both sides of a coin not an ideal work of both and right so what are some of the solutions to this right one is design thinking let me share with you a design thinking right read it out anything about it okay a few the whole idea behind design thinking is essentially what I just gave you but not necessarily in those terms it's all about kind of what happens in the organization and I'll give you some of that right now as another review here's Tim Brown from IEA his view of it is what can we know what's viable from a business perspective what's desirable from a human perspective and what's feasible or possible from a technological perspective we need to take all three sides of that put it together to figure out what we're going to do with the organization from an existing thinking standpoint I have different thinking if I like deductive and inductive approaches depending on which one you pick it's either from the general to the specific or from the specific to the general but that's using existing knowledge and existing points about what's happening right but when you use something about what could be in the future right and taking data points and maybe outside of those current things things that were happening there don't fit my models about the past because they're about the present and so my goal is to identify not what is true from the past from the analysis from the product development side I need to be thinking about what could be possibly true take those data points come up with a new model and use what in design thinking terms called abductive thinking but less important than the abductive title, look at these words that they use to describe it empiricism, in other words an empirical approach hypothesis, experiment, refine you heard that before or of course you have that's the whole androemin approach come up with a model, institute find out how it operates inspect and adapt, continue to do the future but they don't use that term in design thinking literature so you use these talk about the different thinking and how it comes up now this is Martin's view from his book on design thinking a lot of his work is that there is this knowledge funnel I put product funnel up there in parentheses because you use to product development funnest it's essentially the same thing but applying to the business standpoint I have all this data out here I can't make heads or tails out it's just letters and other things I can't realize data it goes into the phone there are four stages from Martin's viewpoint there's mystery I have no idea what this means if you ask me to read all this stuff I couldn't have any idea what it means but the more I work with those data points and I get some intuition about what's happening now I can think about what's going on I can then start thinking about making a heuristic or some rules of thumb about how to deal with it the final stage is systemization or an algorithm with a million algorithms from a software standpoint because that's basically what software is but the design thinking the idea is saying in broader terms for the business it's just that same kind of product funnel that people do when they're designing products for realization think about the business model that's being used to produce the profits how do we make sense of what's happening out in the environment and then work to those stages the same way start with that complex keep going until we have it simple enough and reduced enough that we can implement an algorithm effectively realization implement a system like software that the organization is going to run on so in picture terms there's a whole bunch of data out here there comes the human element intuition, what can I think about this then heuristic we know a lot about but there's no thing that we can program to produce beautiful music all the time it still takes a human element there's still human factors involved and then the key there from those first three steps to the last stage is get it to the point where we don't need human involvement we can reduce it to such a set of rules so a flow and we can also implement that from a systems perspective that we don't need human involvement or very little because the human side is actually the expensive side the whole point of trying to get out of these first three stages to the last stage not just from a private perspective but the overall business perspective is to get it to that algorithm stage why? well, if I take all that the efficiency gains come when I can systemize something I can remove my expensive human components not that we're not needed but if I have to use completely human system it's going to be a lot more expensive than if I can reduce it to software or a machine or something to get equivalent results so my aim is to get it to the algorithm stage from the business perspective have the business specified suitably in the operations end I'm not talking about the private development but the top of that curve, right to maximize that curve we need to get to the algorithmic stage from the business standpoint so we can maximize that efficiency because the only way then that we can invest for the future is to get that efficiency, to get that margin to be able to pay for the exploration and to come up with new models for the future alright, so they're by tracking so far, I know it's around the morning there's a lot of theory here alright, so let's take an example of healthcare IT when I was speaking about GE at their second annual agile transformation conference last year the head of healthcare IT actually gave some things, right, because we've got a bunch of objectives for the year, I looked at the objectives and it mapped perfectly on one hand, he said let's get the business to a point where we can optimize and systemize where we can reduce unit costs by at least 10% unit cost out in GE terms, so let's reduce increase our profits in the curve of what we've got existing from a private perspective, also one of the objectives he gave him there was that every segment must have an annual breakthrough not just improvement not just incremental improvement but a breakthrough, so what he said in design thinking in front of terms, so as we need both of these we don't just need one, we need both the efficiency side and we need the front-end implementation side alright, so I'm going to ask you another question in your terms when your typical task is when you have a project, do you say or do someone say to you, here's the project I want to know all these things about the project and how I want to make them up front and I want you to achieve them with any variation, well I don't need any variation is that what you get? or you get possibly somebody that says just give me a ballpark estimate let me know how we're progressing and how you think things are going and what changes you need I think this is the right thing to do just get started and let's see if it's the right direction and we start getting the results, so just show of hands, when you get a task how many of you get this task in here this is kind of a general idea just go get it, I got one well a few, what about the middle one I'm talking on average right now some more what about the last one interesting, we got a spread typically when I talk to audiences about this it's more on the right side it's the give me the system model plug all this stuff in all these requirements and spit out on the other side exactly what you're scheduling your cost and all the other information is that you're going to have for the project in our terms the waterfall model so the common problem that comes from that, if you hear that is someone who's thinking about that optimization side and they're trying to take that same side thinking over there where I'm trying to systemize, optimize get one answer in and it always gives me the same answer out the other side to the left side of the equation where I'm trying to develop things where I don't know exactly what the answer is maybe I just know I got to put some inputs and then try to adjust as I go so that's a key fundamental problem that comes up and in terms of design thinking that's why because you hear them talk about this funnel and you need all parts of it for the finalization or setup for the right side so applying it to software it's the best that we can do and think about this usually when we develop software we have end goals in mind but we can't guarantee I don't have this black box that I can put the requirements in and spit out the exact set of software that's going to do it on the other side just do that human element that's why we're here to make that difference in what's happening but what I'm trying to do with all my methods is to increase my probability of success and more risk it's not only to get the right answer because I can't guarantee the right answer I can get close to the right answer but it's to have more success in doing so as opposed to the holy grail of what some have tried to do over the years the software has come out with that I'm delivering the process to produce the software that guarantees success we can't operate if the right side exists we have to operate as a center it gives the software factory I put the raw materials on one side out comes the finished software on the other side it's not a factory it's not that December line perspective as opposed to the vague research stuff which is exactly the pushback I got in my early days when I gave them the ballparks and the risks and everything else if I put those two together and follow along with here it fits well because I got my development in part which is up here and I have the operations part when I'm trying to get the margin out so what the design thinkers are saying is perfectly in alignment with what you know from an agile perspective and from the organizational curve we want to have that optimization after the development so we can continue to invest in the future both of them require learning and approaches that we talked about back to our earlier slide the differences between the two areas one it should be and the real question is how do we maintain these opposing views with excellence on both sides not just one side well, if I look at the design thinking literature and Martin for instance here are the points he says that you should do from action points in a reading book I went through it and others in the literature said build your view of the world and your role in it, which is a good thing you need to know the tools that you can use to understand those views and how they organize it and you need experiences build your awareness and ability to discern over time what's happening and then to improve I looked at that and I thought this isn't happening to me a lot this is kind of, yeah I got it but what do I do now so what practically we do now and here's the key marriage point between the concepts is that we reimagine because they fit exactly that fuzzy front end that they're talking about that has to be married with that operational efficiency and everything that you learn about linear management we can do to improve the organization use that as the practical way to implement that design thinking that is supposed to balance the two parts because there isn't much on practical implementation but we've got the keys to the kingdom so to speak in other words what I'm saying is you're the director of the agile dragons you guys, you're the ones who are going there and slicing dice and sharing them how this stuff fits together because you learn a few people in the world who understand how you can balance those things so back to my point earlier is that you're the heroes of the organization and they need you because it's not just a matter of the product or system that you're working on currently the technical one but it's their long term success so let's talk about their own agile renaissance I say renaissance because this is actually a way things used to work and then we got so heavily systemized in the 20th century with the symbol lines and everything else that we were doing that we kind of lost our way this is if our audiences need to know about agile I'm going to bypass these so good execution agile execution of ideas not the execution of the operations part because we know that most organizations have that code they can figure out how to do that on six sigma all those other sort of things not lean six sigma or six sigma product but the original six sigma and if I execute now in an agile way if I take those three reasons earlier talking about why organizations fail I can not only improve my execution but because I'm going to iterate I'm going to take an idea and make it into a good idea that will succeed in the marketplace if it even has a chance of succeeding like Apple I take the idea of a mutant and I come forward they're going into a better one also I'm going to use that power of inspect and adapt to overcome outside events because I'm going to find where it's going to work I'm not just going to go with something that you're going to succeed or fail so the life comes from that so from an execution standpoint if I then apply the agile principles to the stuff that we keep building here the idea of the funnels the design thinking if I look at this stuff up front with a human element that's exactly where agile fits because if you look at what we talked about earlier as far as design thinking and then see all the words they're used here iterative empirical concept of customer value, collaboration just enough to succeed concentration of flow and work and process transparency, inspect and adapt all those sorts of things to the right, but they especially fit over here and so I can move from an operation standpoint my deterministic view of life all being empirical and then try to work and figure out what the interface is between them so in software development terms agile, waterfall and linear is actually an overview from my perspective it's kind of an umbrella that fits across both of them so you hear a lot of arguments these days in the agile community about dev versus ops it's the ops guys with stability the development guys want the agility thing, they want to cycle a thousand times a minute and the ops guys are saying well maybe once every a thousand years but that role of us is coming because think about it from their perspective very similar, the whole role in their life is for stability in operations so from the point that we've been talking about here today is that the reason for being an efficiency side and so both things that they want when they talk here is exactly that side where you're coming at it from the development side also from the business perspective there's a big perception gap that applies no matter what model you're using so let's think about it I make on the right side and that's what we're trying to stretch out to improve to make as long as possible to get as much money as I can out of the existing systems and products on the left side I'm trying to spend it so in terms of the lifeblood of the organization if you will is that money that's flowing in, that revenue what happens on the left side you're spending it so that new organization is these guys they're like vampires they're sucking the organization of blood from us all they demand is giving more of that blood I've got to this point I need some more funding for this project so the reality is is that they're trying to make money and keep as much of it as possible and they demand an organization of vampires that are running around trying to suck it out of us and then think about it this analogy is better than you think so what do vampires do is anybody seen a three-fanged vampire? I assume anybody seen vampire movies horror movies with their hands yes? you've never seen a three-fanged vampire they always have two, right? it's just kind of a given it's a given that they've got a coffin somewhere that's got some dope from Transylvania where they came from that they go back to and they never come out in the daytime well, I hate to tell you but IT folks, kind of the same they go back to their coffins they're cubicles, right? they don't want anybody around it because they've got everything set up just right they're running out of dirt somebody from the organization and I don't want to work at night instead of the daytime so I've gone on this one side these vampires are sucking it up and they come the organization says, you know what? we've got to contain these vampires so what are they going to do? what are the tools that you have to control vampires in movies? it's things like garlic wooden stakes to kill them they use the same thing in the organization things like stage scale improvement processes organization of garlic okay, if we get to have them tell us what they're doing at certain points in time we can keep them from sucking more blood from us because we can shut the thing off before we get to more of it right? the stake in the heart right? so think about it in terms from the perception perspective is that this is kind of a fun way of looking at it if you keep it's sort of a better picture of a vampire whatever you want here it's almost like you're speaking in a completely different way in the same way because they have this view of what they're trying to achieve and you're coming at it from a completely different perspective right? to make it worse this is a survey in the 2000's from Spencer Spirit of the backgrounds of CEOs and company executives how do you come from engineering? not a lot most of them come from finance that's really the realm of multiple members it's giving me a simple member territory of marketing law banking and so on so most of the top executives are tuned, they know they need something for the future but unfortunately the way that they're thinking most of the time because of the pressure from Wall Street or the engines, stock exchanges, whatever stock exchange they're dealing with constant terms, they're thinking in terms of those right side terms so one of the key things you have to do as you're evaluating all this Andrew Lee stuff is to think about how do I translate from the technical approach the technical terminology into that right side terminology how does it correlate? don't speak in terms of we need more blood, we need more funding but raise it down the road the broader picture, move up measure upward in terms of metrics the key here is to connect and comprehend all the things that you are about communications from an agile perspective and all the training that you have and all the things in the future it applies the same way just take it for a different audience moving up the level of how can I terminology wise know what they're thinking, know what the model is like we've been talking about now and then change what I'm saying so that it fits the model that they're hearing and they can comprehend it that's all we're talking about here knowing a different model and what the issues are responsibility for effective communication now I know in communication terms, both sides are supposed to take responsibility for it but in this case, as an interventionist you've got to take all the responsibility and make sure your message gets across right, so from an outside perspective or outside events, let's talk a little about that there's a term that Joseph Schimpeter came up with called the girls of creative destruction so Tom Peters had a view where I read this it's the only industries that are calm or untouched or not rocked by change or those that are either about to be changed or have been bypassed and they just don't know it yet so all those things are going outside if it seems calm now it means that there's a chaos like we're coming or it bypassed you so you've got to know what's going on expectations are no change or unrealistic so here's one of the keys to how you can connect the strategic side of the company is we're trying to make all these changes and talk about it in terms of the in 1970 I believe almost half a million people died what storms do is they rearrange the landscape, if I take a hurricane it changes all those things and all those depths and what the landscape looks like changes, so as those economic storms come through it means that I need to map frequently because I had those who were changing so I have to have a way of coming up with those maps fast, not years but quickly forecast the possible and take appropriate risk because if I wait for those to calm down, what's going to happen? I either have been bypassed by the storm and probably boots somewhere or I've been sunk because I haven't taken the appropriate action and keep working on that and iterate this is a quote I read from the president of Pixar the core skill of Renovators is error recovery not failure avoidance so iterate, adapt inspect what are the key questions you have here? why don't we just scale our agile to the enterprise if this stuff is so good that you're telling me about why we should use it why shouldn't we scale it up to the enterprise? well, the first answer is let's go back to our curves the right side doesn't really need agile per se if you've got a heavy operations focus because it doesn't work because they need stability and the efficiency to be able to generate the money so the first answer is we can't be enterprise agile in the same sense of terms of agile like you're running currently if I look at the context of organization I might have new product development that's NPD or major development I might have existing product development or enhancements, EPD I've got manufacturing I've got operations the left side is where I want all that efficiency stuff the left side is where I want the new product development stuff increase variation, change so let's take some examples mobile apps I don't have a lot on the right side because most of the mobile apps unless it's some kind of software as a service thing you just sell it and then use it using that existing data so I've got small manufacturing once I've got the software done it's not a big area of manufacturing operation I don't have operating it's on the left side so a mobile app business if I don't have any back in I can be enterprise agile because that's all I'm focusing on is that kind of development side if you will if I take any advertising agency something outside of software it's projects based work and most of it is new product development new product being a new advertising campaign whatever it is that my clients need to come up with or giving them juice or changes an existing campaign multiple outputs so I'm existing once again not much in manufacturer operations so they can be agile what about software as a service well guess what now I've got an operations component here the moment I'm an SLS approach the moment I step out of development and go to operations now I have to start thinking about what's best for all that operational stuff to build efficiency and everything else so this is the reverse problem this is where maybe the company or the startup or the product group is all development oriented but not only the language and the capabilities of the right side so if you're a startup or you're thinking about doing a startup keep that in mind if I'm an embedded system now I've got all this stuff if I'm software but I've got the device I've got all that regulatory world around it so I have to have everything for both sides of the equation so the answer to enterprise agile well it depends and agile being more agility not just agile so we can move that way there because if we take the things with asterisks customer value collaboration just enough you know those more but that further work and process can be done we can start moving in to the appropriate areas on the right not everything on the right will be appropriate for all those things so you have to make the adaptation think about it and then inspect and adapt but taking the pieces off and move it to the right for a fusion not either or, but both and okay very quickly on leadership I love this quote by Peter Drucker bad management, in most of what we call management in other words bad management because system making it difficult for people to get their work done so the whole concept here what does it mean to be agile leadership and then most organizational transformation agendas have to do with that operations side how can we improve our current cash flow earnings and everything else it's not necessarily development okay let's go back to that model I showed you earlier four pieces parts the readers design but if you will their product is really the organizational system and if I think of the system in those terms I have two things that are longer term more persistent which is strategy and culture I've got two shorter term levers or things that I can do which is people and processes and systems right readers have to address all aspects I gave you an example here of some of the differences from their product standpoint I mean from a library on the right I have a funnel and innovation on the left from the organization but I can't have just one organization that fits all if it's more fluid and more inspected that that means I'm probably going to need a different organizational model the same org chart concept doesn't fit on the right is on the left so as a reader I have to think through that for the process perspective that's all we've been talking about right I've got to think through how I'm going to balance that and not only from a people perspective not only those things but from a people perspective it means likely that there may be different types of people working on those different things right and the CEO of a reader has to be the balancing force so when the question comes of how do we balance that a lot of it lists square in the lap of leaders of the organization right team and down to the team lead perspective different kinds of decisions again I talked about that we'll keep going the deterministic view I think you probably know this is that I can predict outcomes if I have it if changes are needed I have failed right so my perspective if I have a deterministic view of life is that if I have to make a change I've failed which is not exactly the whole point right that's just that right side right whereas also if I take efficiency as king as my viewers I'm trying to maximize realization it's this simple line approach try to get everything as much out of everything people in process as I can removing non-revenue activities but non-revenue is what? my organization of that I said they're the ones who are going to bring the future revenue it's not a question of revenue it's a question of revenue now versus revenue for the future okay and this is why there's a lot of words there that's the whole reason of why organizations that try and take innovation approaches to life and just try to take some program from the right side usually don't get good results because what they're trying to do is apply that stuff that comes from the left side to anything that's built from the right side it's just like deflect right off because it doesn't stick because it can't stick so the whole point of if you want to up the innovation in an organization or from a product development perspective you have to work on the model of the organization not just on innovation itself right perspective and then this is Conway's law many of you that have seen this before said an organization that designs the system will inevitably produce a design whose structure is a copy of the communications processes or structures within a company that's just the kind of way it works this is a statement by Conway that you may not be as familiar with because the design that occurs first is almost never the ideal the revenue system concept that may need to change therefore a flexibility organization is important to effective design right now for them obviously we don't stay the same with organizations so from the concept of that is let's go for one here first why don't we view real orgs if you're an organization oh gosh another real org is coming right why do you respond that way it's because it has nothing to do with real effectiveness of the work it has to do kind of with power structures and communications and all that kind of stuff right what we really need to be doing is thinking of real orgs as ways of inspecting and adapting the organization forward in time and coming with a more positive view of them as long as they're branded involving people in redesigning their own work because they're the ones who know how to work best and they will support what they create so we're thinking of questions for you by the way I'm already giving you a lot of questions but here's some more is we were seeing in other sessions how do I apply this to the organization especially just to the structure when the most common things that organizations have the org truck how do I apply continuous improvement to the design of that org structure how do I apply continuous improvement to the overall business change the shift not just from continuous improvement for the product but to the organization culture I'll just zip to this should these have the same culture if I take any kind of Inland Revenue or internal IIS in the US or income tax department here in India should these two organizations have the same culture why they shouldn't have the same culture because they have different strategies they have different aims in the organization so the culture should fit I know you would prefer that they have okay that looks about right I'll just take that right no they've got rules this is high efficiency it's getting the revenue right certain rules stuff and rules not about it but that's because they're strategies and their outcomes are different so you have to tag the culture to what you're trying to do this also means that inside the organization you may have to learn how to have separate cultures into exist at the same time most organizations try to have a unified culture all the way through down to the detail level well at the top level yes that's good because we want organizational identity so if someone hears about Google or they hear about companies that work like Google they're usually referencing the culture not the product necessarily but work like Google a certain set of things the top level that's good but in each individual unit that may not be good you may have to have adaptations okay so the manifesto from a culture perspective if I take four components of culture or four types of different culture meaning a mix of collaboration how much do we create how much do we control the manifesto next session I'll get into detail here the manifesto says is that we want a balance of all these things somewhere in the organization as opposed to an overweight on the control part right the hierarchy part the command and control the deterministic view that says I can come up with something at the beginning and control it all the way through right it's a dramatic difference between the agile approaches and what life in most organizations is but it's also a barrier to agile adoption so when you're thinking about agile adoption you have to do culture one last thing to review with from a leadership perspective you need new CEOs I don't mean the people some of you may want to replace the people but that's not the point here notice that there's periods after that what we need is to think about the stakeholders of the company as being the C customers the E the employees the O the owners or the business itself what's the income or revenue and significant others they have different views on life it's not like some there are some people that say customers should come first others say employees should come first others say that's all about the financials well what I'm telling you is to be successful long term maybe not short term but long term you have to focus on all these to be able to survive and thrive you have to look at what the quality of service and product are for the customers you gotta look at the work life for the employees you gotta look at the financial returns right that produces this kind of Fortune 500 approach and this is a USA buy as I put it there is that instead of a balance it's usually about maximized value if you look at any of the stock exchanges that's what we want is a short term gains all about finances right whereas yes, we want enhanced value we want more returns I just show you all that modest stuff about we need those returns if we're going to be able to do any product development in the future but it's not just to that or to the exclusion of all the others just deliver legendary service for our customers we need a more fulfilling work environment for our employees so that they not only can produce now but they produce more in the future right and are committed to what they're doing because you know from when you work if you're not committed to what you're doing you don't do your best work and if you don't have any major stakeholders out there and you have partners that they feel a shared responsibility with so the movie is for the CEOs and you the primary responsibility this is all the way from a team lead or anybody who's taking a leadership work all the way up to the top your goal is to work on the organization not in it or maybe it's both but you have to work on that organization your product is the product that produces the product the system that produces the system okay we define CEOs in the terms of just giving you and be a servant leader but one that guides and makes sure that all four parts of those constituencies are served and using the agile principles to balance both the innovation on one side and optimization on the other and then the real kicker is anyway keep doing this over and over keep working in the system that produces the systems you know from Gandhi's perspective he wrote on it this famous quote is that don't wait for others to do it start with yourself start with the area that you can impact and then expand from there if you can't affect the entire company at the beginning well that may not be but you can at least affect the area that you're in right so be an example from this stage perspective since I'm a producer at this stage I'm also obliged to give you this speech to come to the other ends all variations on this theme but really more specific to parts of the model what about that uncertainty that occurs in business the session right after this we'll talk about that how do we deal with that uncertainty customer value is key both in leading and agile but how do we qualify that how do we put the terms of value in terms that we can work with from an innovation perspective also we'll be talking about that I love this title structured freedom with rules and strategies now does that fit the balance of exactly what I'm talking about structured freedom with rules and responsibilities again follows after that risks and strategies this is all about risk how do you deal with that and meet large scale perceptions in Malaysia what do you do with a big bang agile well out Matt works for center we'll talk about that continuing adventure from Yahoo's perspective of the agile transformation Yahoo's history they started stopped and started again so it's a fascinating story there and in a case study outsourcing world is what do you do when you've got to deal with contracts but at the same time you have to deal with collaboration and all those other agile values so lots of good stuff to come from a stage perspective as well as all the others that are out there so take what you learn and my pitch to you is to apply it to the system that produces the systems so questions wise we try to fly through this I will be here the entire conference where the speakers corner and add me afterwards you know this card call me later fine that's on here to help you so the action here is an organization achieve mastery when the prime values are there connect and comprehend what have businesses how it operates so you know the model if you don't know the model you can affect it positively commit to making a change and exhibit courage and doing so because it's not going to be easy I think the value is necessarily easy so it's going to be rough sometimes you've got to get through that and then implement inspect and adapt frequently map take action think about the CEO's model and review and repeat so just brief recap there's another thing of the organization here are the three levels that you have that you can apply from the agile map agility is that life frame that can help you overcome from an organizational perspective the near-death certain death that faces it think about in terms of from an inside piece of the organization being a lean and agile powerhouse to coming to a business powerhouse from an area to what the company is if you don't like change you're like irrelevance even less and change implies some pain think about the long term objectives if the organization can't take it well maybe they can't but you've got to put it back in the terms this means life and death here this isn't just some numbers game here help overcome that pain threshold and back to our original statement we've seen the hero it's actually you and I think you can have that impact on your companies and your organizations so one more take everything you're doing in this track and the others of the conference and you can be the hero thank you