 Hello, good morning, everyone. We are here on another series of the Agile India webinar. And this week we are fortunate to have Jim Heismitz with us. Jim, as you guys might know, was one of the Agile signatories. Personally, for me, Jim has been a very big influence. I first read his adaptive planning book, adaptive Agile book. And really, the gist for me was that plans are useless, but planning is important. And I think that's basically what I learned and walked away. And I'm actually very happy to have Jim here. We were trying to get him to come and do a keynote at the Agile India conference, but that did not work out. But nevertheless, we have him live today with us. And I can hand it over to Jim. He's going to be talking with us for another 30 to 45 minutes. And then we'll get into the question and answer session. Over to you, Jim, and thank you for joining us today. OK. Thank you, Nuresh, and thanks for that introduction. Let me get my slides up here. All right. Can you see them? OK, do you see my slides? Nuresh, can you hear me? OK, can you see me? I can't hear you anymore. Can you see my slides? I was on mute. I did see your slides. I'm sorry. I was on mute. Sorry. That's all right. OK. So thank you for that introduction. And good morning, everybody. What I want to talk about today is adaptive leadership, really from a level of enterprise agility. One of the things that I've found over the years is that we do a pretty good job of implementing agile projects. And we can go into organizations and we can do one or two or three or four very successful agile projects. But we're not as successful in doing kind of agile transformations in the enterprise, either within an IT organization or within a lot of enterprise. So that's been the thing that I've been working on the last few years, is really this whole idea of leadership and what leaders need to do differently. In the agile community, we've been pretty good about having role definitions for developers, for testers, for product owners, and pretty good about what they need to do differently in an agile environment. But we haven't been as good about telling management, this is the job of management in a new agile environment. We've said things like, well, just don't micromanage or buy pizza and get out of the way. But we haven't been real clear about what the role of managers are in this new kind of agile, adaptive world. And so that's really what I've been concentrating on the last couple of years. So what are the goals of an adaptive leader? And I really break this down into three areas. Why agile, do agile, and be agile? So why do we need to be agile? Part of what we need to do there is kind of envision the kind of enterprise we want, responsive enterprise that responds to technology, responds to customers. And what is our vision for that? One of the things that I find is that organizations don't spend enough time really trying to figure out why they need to be agile. Is it just a software engineering thing? And we just need to get a little bit better at software engineering. Or is agile really more of a business objective or a business goal? Secondly, doing agile. So from a management perspective, what do we need to do in terms of doing agile? What I think is really important is figuring out how to deliver a continuous stream of value. And I think there are a couple of key words in here. Value. So what is the value we're delivering to our clients? And a continuous stream, it's not just once, but it's over and over again. So we now have a lot of emphasis on things like continuous delivery, in which we can deliver software on a very frequent basis. And deploy software on a very frequent basis. The real question from an enterprise standpoint is can we use software on a very continuous basis? And then thirdly, kind of being agile. So it's not enough to know the agile practices, but you've got to kind of embrace the agile principles and really behaviors. And so how can we be agile? How can we create a collaborative, innovative culture? So these are really the three goals that I've set out for adaptive leaders. For the last, since about 2004, for the last eight years or nine years, IBM has done a study every couple of years of CEOs. And they interview 1,500 or so CEOs worldwide. And they ask them, what are you concerned about? And for the first time in 2012, technology was the number one concern of CEOs worldwide. Every year before that, it had been something like economic conditions or business conditions. But in 2012, it's really technology. And really, when you think about the changes in technology that we faced over the last few years with the cloud, with mobile devices, with social media, with the internet of things, with big data, each of those things can have a big impact on organizations. And yet, a lot of organizations, according to the economists, think that agility is really a key to organizational success. And this is organizational agility, not just software development agility. So this idea of agility, responsiveness, flexibility is really important in the executive swing. And I've really broken it down into what I call responsiveness and efficiency. And do we respond to the market as our primary strategy responsiveness and responding to the market, responding to technology, changing as we need to change to respond to customers and to give customers a good customer experience? Or is our prime focus on efficiency and making things as low-cost and efficient as we can? And it's not that one is wrong and the other one is right, is that one is the objective and the other one is the constraint. And the difference might be the difference between, say, Google and Walmart. Whereas Google is really focused on experimentation and getting new products out there and responding to the marketplace, Walmart by and large is more about efficiency and low cost and driving cost out of their distribution system. And efficiency is really their primary objective. Are there places where Google wants to be responsive? Of course. Are there places where Google wants to be efficient? Of course. But those are not their sort of primary drivers. Let me just give you an example of this from my experience. And this is kind of the opposite ends of the spectrum here. About 20 years ago, my wife and I went out to a chair to a warehouse, a chair warehouse that had lots of different chairs. We needed a chair for our living room. And so we looked around the showroom for quite some time. We finally found one that we really liked. We went to the salesperson, got all the paperwork filled out, and wrote a check and said, OK, we'd like to put the chair in the car. And the salesman said, well, you can't do that. He said, why not? The chair's right here. We'll just take it and put it in our car. And he said, well, our computer system runs tonight and it doesn't issue picking tickets until tomorrow. And so you'll have to come back tomorrow when I have a picking ticket for your chair. And I thought at the time that this was pretty odd. But it just shows that those particular systems built in that day were really focused on systems of record and internal efficiency. And they were not focused on the customer experience. Contrast that with Natural Markets Food Group in Toronto, Canada. And ThoughtWorks has just done a big project with them, where they put a new store in a mall. And this new store has grocery items. It has a bar. It has food. It has a restaurant. And the whole place is built around customer experience. You can order on your smartphones. You can order on a touchscreen on the wall. You can sit at the bar and have a drink and order something from someplace else in the store. And they'll have it delivered over. You can check out using your iPhone. So they try to make the whole customer experience as seamless as possible and do it in any way that you want to do it, as opposed to how they want to do it. And I think that's the difference between an organization that really is looking at systems of record and efficiency versus customer experience-driven systems and responsiveness in the future. And does this idea of agile and innovation, is that really, does agile really foster innovation? And the one example that I can use is Salesforce.com. And Forbes Magazine, the last two years in 2011-2012, ranked Salesforce the number one innovator by innovator. They had about a 40% five-year average sales growth and mid-income growth of nearly 80%. Steve Green once was their VP of Technology. He left about a year ago to go to Twitter. But they had 140 agile teams in 2011. And the whole idea of agility really permitted their organization not only in software development, but in other areas also. And Steve has been quoted in several talks as saying agile was really the foundation of their innovation. And so innovation, responsiveness, all kind of go together. And I think a lot of organizations need to be a lot more thoughtful about their vision for agility, for responsiveness for the future. So that sort of leads us to the second part of this, which is really practices and processes around doing agile, around really how do we deliver a continuous stream of value. And what we're really looking for here is you have business goals, you have responsiveness or profitability or market share. And then you have product delivery capabilities. You have agile, lean, con bond, some XP, lean startup, which is really more product discovery than it is product delivery. But it still is one of those things that we need to think about quite a bit. And what are the execution levers that management has to turn business goals into products that will provide the right kinds of experiences for the customers? So what are those execution levers? And I think there are really four that I've been talking about. And I'm really gonna focus in on just a couple of those today. It's really quality. And why is quality so important in things like reducing technical debt? And I'm gonna talk about that in just a minute. And then I'm gonna talk a little bit about value. It's also important today, everybody's talking about doing more. But in many situations, we really need to learn to do less. We need to really focus in on those most important things and do fewer of them and do the few things we do well. And then as a manager, one of the things we have to do is build capabilities from our organization. So I'm gonna focus in on quality and speed to value this morning. And again, the objective that we're trying to do here is not to deliver a system or an application or a product release once or twice, but it's to deliver them over and over again as the business changes, as the business adapts. How can our software keep up with the business changes? And what we're saying now is sometimes the business can't keep up with the software changes that we're able to do through things like continuous delivery. So this is actually a picture taken somewhere in the world. I will kind of mention where it is of a distribution network for electricity. So the question is, is something like this, do your systems look like this? Do you have some systems that look completely intertwangled like this? And secondly, do you think that kind of impacts your agility? And so we know things like high quality and reducing technical debt do impact our agility, but what happens is we've kind of gotten caught up in technical quality issues, code quality, design quality, automated testing, technical debt reduction. And when we talk to our customers or our clients or our users about these kinds of things, really what they're hearing is kind of blah, blah, blah. That's what your business partners here. They are really not kind of geared in to quality at a technical level. And so we're really addressing the questions to them, the long kinds of questions. So the historical dilemma that we've already always gotten into with people, with our clients and with our business partners, is do you want features or do you want quality? And what we're really asking them to do is we're asking them to trade off a business outcome for a technical outcome. And we're gonna lose that every time because they're gonna always pick the business outcome. So we're saying, do you want more features or do you want a reduced fatigue complexity index? And so that's a pretty easy outcome for them to decide on. So the real question is, what if, what if there was something else that we could talk to them about, something that was important to them from a business perspective that we could ask them to trade off features against. And I would offer that that is a business outcome versus a business outcome, and that that in fact is cycle time. And cycle time is dependent on high quality. So if you wanna reduce cycle time, you've gotta increase automated testing, you've got to reduce technical debt, you've gotta do all of the technical things that we know how to do. But it's, the end product is reducing cycle time. And so now in order to get the question is really, features or cycle time? If you want us to increase, to decrease your cycle times, you may have to back off a little bit in features so that we can give you things on a more responsive basis. And there really at least three different kinds of cycle time that we might talk about here. One is the cycle time to get a story from the backlog into production. The second one is how frequently do we actually deploy? Once a month, once a week, or seven times a day? So what's the deployment cycle? And then for some organizations, what's the project cycle? Is it typically three months or six months? So we can look at each of those different kinds of cycle time, and they're all important. But really the most important thing is to look at features in cycle time. And I actually think this is gonna be the really important measurement criteria in the future is features in cycle time. Talk a little bit about value. One of the things that I've noticed as I go around and I see what people are doing with agile projects. And I always ask the question to people, do you ever run into a situation where you're asked to be flexible and adaptive and responsive, but at the same time somebody says you need to make the plan. And that plan is typically cost schedule and scope. And I think if we really want agile organizations, we have to rethink the measurements that we're using to measure success. And so I would say that what we wanna measure is really value, quality and constraints. And those constraints are cost schedule and scope, which used to be called the iron triangle of project management. But the first thing is really value. Are we delivering something valuable to the client? And are we doing it time after time after time? Do we have a continuous stream of value? So the question, for example, as we go through a project, is not have we delivered all of the scope items that we talked about in the beginning. The real question we need to ask every iteration or every release is do we have a releasable product? Do we have enough functionality that we can release this product as we intended during this iteration? And so it's a top-down question rather than a bottom-up question. It doesn't say, did we get all the requirements done? It says, can I release the product? And is it a valuable product? Secondly, I wanna talk about quality and we could possibly put in here cycle time, but is it reliable and is it adaptable? Does it do what it's supposed to do today and can I adapt it for the future? And only then can we look at constraints. And let me say here that constraints are critically important. The schedule may be very, very important for a particular project, but it is a constraint. It is not an objective. The objective are value. Do I deliver something of value today and quality? Does it work today and can I deliver it over and over and over again? So efficiency management by and large look at things from the old iron triangle perspective of scope scheduling costs, but responsiveness management, agility management, adaptive management really begins to look at things from a different perspective of value, quality and constraints. So I think if you are really moving towards a more responsive organization, a more adaptive organization, which you have to think about organizational measurements and changing those, or we're gonna get stuck trying to measure success in this new environment according to measurements that we used in the old environment. So for example, one of the things when we're talking about value that I talk to people about is that in the past, when we did waterfall projects, we didn't really get all the value until sort of the end of the project. With an agile project, as you can see here, you begin delivering value earlier on in the project. And so the real question as you go along in a project becomes things like, would I rather have 100% of the value for 100% of the cost? Or as you can see on this chart, I like to stop this project early and get 90% of the value for 70% of the cost. So it changes the way I think about when should projects terminate? Maybe the next most valuable thing I could do is on the next project or the next product. And so really looking at value versus cost is an important aspect of really adaptive leadership. And what's the right cutoff point? So strategies, the most valuable things first, I want to evolve features over time and of course determine the right cutoff point. So I think the drivers of the future in terms of things that we want to look at from a software development standpoint, in terms of how we measure success, are really measuring value and measuring cycle time. This was a project done by Gary Gruber and his team at Hewlett Packard several years ago. And they wrote this book on large-scale agile development. And it just, you can read some of these numbers, shows that what you could do with a large distributed team that really took a look at reducing cycle time, they used continuous delivery. In fact, they started with continuous integration, continuous delivery, and kind of revamped the software for the whole HP LaserJet software line. It took them about three years to get this thing all ironed out. Of course, it didn't take them that long to deliver the first product. But they did some great things, like reducing cycle time from two months to a day, putting a lot more money into innovative kinds of things rather than just keeping the basics going. So the last part of this is really being agile. It's how do you create an innovative, adaptive, agile culture in an organization? So how do you move from sort of the traditional command control to what I call adaptive leadership? Other people have called it radical management, management 2.0, management 3.0. There are a number of different people who have offered some different styles of management. And so there are a number of different books out there. And we have it really coalesced around a name for that style of management of leadership like we did for command control management or like we have done for agile software development. So there's really not a widely agreed upon term for this sort of future of management. The story that I like to tell about this style of management actually was from Walt Disney. And the making of the Snow White movie, Snow White and the Seven Doors back in the 1930s, of course, as one of the first major animated films. And Walt Disney got up in front of his group of animators. And basically acted through the entire movie himself. It took him four or five hours. But he played the princess, he played the Rick and Rich, he played Grumpy, he played Doc. He played all of the characters and basically visualized for his staff what he wanted. And then he put some boundaries around it. He said, I'd like to have it done by Christmas of whatever year it was, 1934. The staff is going to be about this big. So he kind of set the constraints in terms of resources available and delivery time. And then he said, and let's all work together on this. Here's how I want to collaborate. I'll be the sort of product owner. I'll tell you the things that I like, the things I don't like. So he created a vision. He created a collaborative, innovative environment. And he made some constraints on it. And he basically said, you're the animators. I don't know how to do the animation. Go to it and we'll work on this together. So it was a different style of management that he used. And so the four pieces of this that I really talk about that I think are really most important, and that doesn't mean that these are the only four, adapting, exploring, writing, paradox, and engaging. And I'm not going to talk about all of these this morning. But I, in particular, I'm going to talk about one of them, adapting. And I'm going to tell you a little story about a situation that happened to me about 20 years ago. I went to Toronto to teach a workshop for a government agency there in Toronto. And I don't remember the name of the agency. But they were holding the class in one of the downtown buildings in the Sun Building. And there was a training company that was providing the room. So it was a government agency. And then it was a training company. So I went in the building the first morning, went up to the 11th floor, got off the elevator, checked in at the desk, went to the training room, had a good first morning in the class. I think there were 15 or 20 people in the class. And a half dozen of us decided to go to lunch to go. So we went back in the lobby, went down in the elevator to the first floor, and took an escalator down to the underground. Now, Toronto gets very cold in the winter. And there is a huge network of underground walkways. And on these walkways, there are stores and restaurants. And a lot of people in the wintertime never go up the ground. They just stay down and walk from building to building on these underground passageways. So we had lunch. And I decided to go outside and walk around a little bit. So I went outside, walked around a little bit, went back in the building, went up in the elevator to the 11th floor, punched it, got out of the elevator, and there was no room there. There was not the room, there was not the floor that I had seen my previous attempt. And so I got the winner. So maybe I got the wrong floors. I got back on the elevator, went to a couple of other floors, still couldn't find the room that I was looking for. I was beginning to get a little worried here. I was getting late for class. And I was the instructor, right? So I shouldn't be late for class. So I went back down to the lobby. And unfortunately, I had remembered the name of the agency that I was teaching a class for, but I had not remembered the name of the training company whose room we were using. So, but anyway, I went back to the directory and I looked through the directory, and nothing rang a bell. And all of a sudden, I sort of looked around in the lobby. And I noticed that there wasn't an escalator going down. And we had come down in the elevator, got on the escalator and went down. And I thought, what's going on here? And so I went outside again and I looked around and there were two buildings. One was the Sun Bank building and the other was the Sun Life building. And I had gone into the wrong building off the street. I went back over to the other building, went up in the elevator escalator to the 11th floor and that was the right floor. I went into class, I was about 10 minutes late. And of course we had a chuckle about my getting lost. But what I kind of remembered from that was that don't get lost in Toronto. The map is not the territory. And I've heard this phrase a lot, the map is not the territory. But from an agile management perspective, it's really hard for a lot of managers to embrace the map is not the territory, to embrace the fact that the plans are actually probably not gonna work out the way you thought they were. In fact, they may not work out any close to where you thought they were and that they might need to be changed and changed fairly substantially. It's actually harder to manage that way because if you really try to drive the plan home and not really look at reality and what's really going on, you only have one thing to plan. But if you really look at reality too, what's really going on, you may find that you need to adapt the plan. And so there's always a contention about do I continue to go down the right road of how I planned it or do I adapt? I started out thinking I was going into the right building on the right floor and I ended up in the wrong place. So I kind of try to remind myself all the time when I'm thinking about how you go about planning and managing projects, not to get lost in Toronto and the map is not the territory. So I have to keep kind of reminding myself of that. And I think it's one of the harder lessons. It's easy to say I want to adapt to the situation as I move forward. But I think it's very, very hard for many of us trained in sort of traditional approaches to actually be that way as we go through. The second part of really this adaptive leadership and building an innovation innovative environment, and it's really what I'll call exploring. And I just want to say something fairly quickly here. The difference between plan, do, and envision explorer, the traditional approaches to projects, to software development, to other kinds of projects was really planning out it, plan it out in detail and then do it and check off the steps as we go through. Whereas the agile approach is really envision as Walt Disney can give, where you're going and then explore into that vision through iteration, through experimentation, through spikes and know that some of that exploration is gonna go right and some of that exploration is gonna go wrong. But it's a really different way of thinking about doing a project is kind of envision where you're going and explore into that as opposed to plan it out in detail and then do it. And those two things, the exploration and the adaptive are I think difficult things for leaders to embrace, for managers to embrace, but I think it's really important if we're gonna build flexible, responsive organizations. So the goals of adaptive leaders, I'd just like to review is really why the agile and build a vision of a responsive enterprise. And again, there's something I think people don't spend enough time doing. I need to think about each part of the organization, each function in the organization, each product in the organization, the organization as a whole and how responsive you need to be and why do you need to be responsive? What's the cycle times that you need? So this whole idea about responsiveness and really driving it down to a detailed level of business objective that I think is necessary. Building a continuous stream of value. How do I as a manager help my organization measure value, define value and deliver the continuous stream of value? It has to be through really understanding what value is, assigning value to projects and features and stories and then working on the quality aspects of how to reduce cycle time. And then creating an innovative collaborative culture is really thinking through how to be agile, how to be very adaptive and have an exploring mindset. And with that, I'll sort of wrap it up. I think I've covered my 30 minutes or so. There is an e-book out on adaptive leadership that I wrote last year and I also do regularly blog on this topic on my blog. And with that, we'll send it back to Marish. Right, Jim, thank you and you've blissed through your slides. I think there's so much great information in there. I just didn't realize we've gone through 30 minutes already. Yeah, I've been tweeting about what you're saying and just trying to get the word out. A lot of gems in there. So thank you for sharing that. I'm waiting for people to ask questions. I did have a couple of questions so I'll get started and then we will see as questions roll in, we will, you know, I'll try and post them to you. All right, so I think just picking on the last thing that you were talking, you talked about exploring and adapting is actually very hard or very uncomfortable for leaders, but yet extremely important because without that, you're not really gonna embrace innovation, you're not really gonna experience the agility if you will, right? So do you have any specific, like any concrete advice that people could look at when they feel uncomfortable exploring and adapting, you know, what any specific advice you would have to for people to get started with that because that's uncomfortable? Well, I think the first thing is to figure out how to become comfortable feeling uncomfortable. I think you hit the right word. You're just gonna be uncomfortable for a while and you're gonna, I had a CEO I was talking to a couple of years ago, CEO of a company and he said, you know what he said? We had 12 initiatives for this year. He said we're six months into the year and we've eliminated, we've taken six of those initiatives off the table, we killed them and we've got six new initiatives. He said, I don't know if we're being adaptive or just poor planners. And so I think that's the kind of uncomfortableness you get because it is uncomfortable to think, okay, am I adapting, am I just not planning well? And it is a more uncomfortable place to be and you're just gonna have to think through that and I think part of it is starting with smaller things and getting more comfortable with approaching it like that and what happens, of course, is that some of our management guide posts we used to be able to plan out a project and we had certain guide posts, we had a requirements document and a design document and it made us feel good until the end of the project when nothing happened and the project went down the tubes and with an agile project, we feel more uncomfortable during the project, particularly in the beginning but as we progress through the project we feel more comfortable because we're actually getting delivered software. So it's in a traditional project, we feel comfortable in the beginning and uncomfortable in the end. In an agile project, we feel uncomfortable in the beginning and comfortable at the end and so it's just learning that that's gonna work out like that and I think that's the tricky part for people and there's no silver bullet about how to really do that other than you gotta go through that experience several times and realize that it does work. Okay, so to summarize, I think you have to get used to feeling uncomfortable and that's nothing wrong with it and in fact, and I would slightly paraphrase what you said is that feeling uncomfortable is actually a good indicator that you're on the right path. You're not feeling comfortable, you're not being adaptive enough. Yeah, it gives you a false sense of security in some sense but you actually, the chances of you driving off a cliff is much higher. So it's okay to be uncomfortable, embrace uncomfortability. Cool, cool. The second question I had for you, Jim, was you talked a little bit about do less and I think in my personal experience, doing less is one of the most important things that I got out of agile is this whole thing that the manifesto talks about as one of the principles is the out of simplicity is about doing less. It's not about trying to do more and more of stuff but it's to trying to figure out what is the most important thing and just doing that. So would you have any advice for people to really focus on doing less? Well, a couple of things and of course the doing less has kind of been carried forward by some of the lean startup stuff in terms of the minimal viable product kind of approach to things. And there have been three different studies done. They were done about 10 or 12 years ago about software. One of them was done by the IEEE software, one of them was done by the Defense Department, one of them was done by the Standish Group. And all three of those studies basically said far less than 50% of code is rarely or never used. And more than 50% of the code is rarely or never used. And so it's a lot of stuff that got put in there because somebody said, oh, this would be a nice feature to have so we put it in there. The thing that I always point to that is a good example of over engineering are TV remotes. They got 97 buttons on, right? And not only that but you have four different remotes, one for each device and so it really gets complicated. And that's kind of how we built a lot of our software. We got too many buttons to push. And so we need to simplify it. Some do it in the first place. And that's one of the things about Agile. At every place in the process, we kind of window things down. You know, at a traditional project we have a big requirements document and then we deliver it and then we build it. In an Agile project, every time we take a story off the backlog, we say, do we really need this story in this iteration? We only have so many stories that we can put in here. Maybe this is not one that we need to do or maybe we could do, we think this has 12 story points on it. What could we do if we only did six story points work? Would we get enough value out of it? And so we're constantly sort of saying, do we need to do this project or the other project? Do we need to do this feature or not do this feature? And so we're constantly sort of looking at the value we're gonna deliver and whether or not we wanna do it. I think that's one of the real pluses of Agile. I also think it's one of many reasons why measuring productivity is very, very difficult and we shouldn't be trying to measure productivity in a knowledge-driven development activity like software development or product development. The idea of productivity doesn't make much sense because if I do a lot less than you do and yet I get more value at a lower cost then I've really got more performance than somebody else who delivers all this stuff that's never used. That's actually brilliant. You should not be measuring productivity in the traditional sense in a knowledge environment where it's really hard because you can have a lot of output but very little outcome and it's not to measure outcomes. You don't even have to be doing traditional development. I wrote an article a couple of years ago said that the title was Velocity is Killing Agility. It is the over emphasis of many people in our community on velocity which is a type of productivity measure the way a lot of organizations are trying to use it and it's causing them real problems. Yeah, I would actually argue that measuring velocity is really measuring how fast you can generate junk but it doesn't tell you anything about how valuable it is until you actually get out there and get users using it and actually have a real impact on the way they do things. Somehow I think we've missed the point and I think in some sense the lean startup, you touched a little bit about lean startup, I think in some sense lean startup seems to be driving that point pretty well is that don't just go off in the ether and start building stuff and try and experiment early on and try and really nail down the problem before you go off sprinting because you could really miss the forest for the tree. We have a question here from Kathy and she's asking, Jim, you talked about Agile Value Curve and I am wondering if you have any advisor guidance on expectations to set with leaders on adoption or adoption that must first take place culturally before the real value is realized through Agile? Well, I think that is what this sort of adaptive leadership is really all about is trying to talk to leaders about what their role is and when I talk about responsiveness, I really want leaders to think about responsiveness from a business perspective. I want them to think about value from a business perspective and then for example, we should be, we in the systems development community, we should be taking projects and as we break projects or products down into features, we ought to be looking at what is the value of each of those features and they're through the assignment of value and there's some ways to go about doing that so that I actually can keep track of value delivered over time and we may do it the same way we do story points in terms of its relative value, not absolute value but this whole kind of focus on what are the criteria on which we build a new product and what are the most important things from the business perspective and it's more than just return on investment but it may have to do with social issues, it may have to do with taking advantage of new opportunities and so one project is more valuable than another because it gets us into a new marketplace so there are a lot of different aspects of value and I think the more we can talk to management about value and responsiveness and cycle time and things that are important to them, the more support we're going to get for sort of the agile transformation. All right, thank you, Jim. That was a very good answer. I hope, Kathy, that helps you. We have another question which kind of is kind of a follow-up question to this. This is Frederick asking, how and when do you suggest we measure business value adding on to his question? It's not instantaneous. It takes sometimes time for companies to realize the business value so what would be the right time to actually measure it? Okay, so there's two aspects of that. One is as we get into a project, we are trying to forecast what the value is, what value we're going to get out of it and so companies for a long time on projects and big systems have done return on investment types of calculations to try to determine what the value of a project is, for example. Fewer companies then go to the point of did we actually capture that value in the marketplace? Some companies are doing that better, particularly some of the companies that are more internet-based or mobile-based and they have different feedback mechanisms that they can use to actually determine if a particular product or a feature or a product or something like that is returning more value to them and they get better and better feedback mechanisms and some of the measurements stuff that the Lean Startup Movement has brought in has addressed some of these things. There's a book that was out about a year ago called Lean Analytics that really gets into this idea of how do you measure things fairly quickly and fairly responsibly so I think we're getting better at that and we just need to continue to look at new and better ways of forecasting value in the beginning and then actually measuring that value and getting some feedback on that fairly quickly and again, the more we get things like mobile and internet and then the data analysis that comes out of that, the more we'll be able to do that. Sorry, I was just kind of trying to get a tweet out. Cool, so I think that's a really good advice in terms of, and you talked about how some of the things from Lean Startup and especially the Lean Analytics is helping us trying to measure what we had forecasted in terms of business value and seeing whether our hypothesis about the business value actually materialized or not. They also talk about doing split testing or A-B testing as a way to have a hypothesis, figure out two different experiments, run it and then have a way to see which one worked better and then invest more on it and these are all again, interesting ways in which we could measure business value. We can compare it to something else we could have done and also it puts us in that experimenting or exploring mindset, which I think is again, very useful for leaders. All right, Jim, I have one other question from my side which is, as leaders, I've seen a lot of companies trying to basically, they've got something working and they spend a lot of time making that better and they're trying to constantly focus on, the kaizen part of it is to gradual small improvements, but very few leaders I've met who actually believe in trying to do disruptive stuff, trying to say, okay, this product is already making money for me, but let me go in and actually do something which actually might disrupt this but make the company to the next level. So what is your advice for leaders to embrace more of disruptive change or the kai kaku kind of mindset? I don't know that I have any. I mean, everybody knows from reading all the management books that they should do that, but a lot of it has to do with timing. If you've got a huge revenue stream from an existing product and you've got a cost structure built up because of that product, then it's really hard to change. I mean, Clayton Christensen wrote the book on disruptive technologies and how you deal with that and it takes a lot of very savvy management to figure out how to navigate getting kind of de-investing in a current project to reinvest in new opportunities, but I think that's becoming more and more important and I think a lot of CEOs are realizing that. They don't all really know exactly how to do it, but I think there's some, there are some things out there, some techniques and processes out there that people have used to really look at new opportunities and how new opportunities come along and how they ought to invest in new opportunities and how they ought to, at some point, de-invest in existing stuff, but it's a very difficult thing. I don't think there's any silver bullet for that one. You're right, I mean, absolutely. I was not looking for a silver bullet and I don't think there won't exist yet. In fact, I've got interested in this whole adaptive chain cycle a few years ago. I was introduced to the adaptive chain cycle and they talk about how we go through these four stages of reorganization, exploration, conservation, and release. And we go back in cycle and they talk about you're like an early startup, you are exploring, you figured out something that works and then you get into this mindset of what they call as conservation where you try and maximize your return on investment and you don't wanna do anything different and you wanna basically keep doing what is working well. But at some point the market conditions around you changes and things around you changes where you become vulnerable to, you become vulnerable and you collapse very quickly and a lot of companies keep pushing that conservation as far as possible and then they have catastrophic failure. And I actually met one founder who really understood this and he said, we actively go in and when we feel that our products are kind of stabilizing, I go into office and there's no new problem that I have to handle, I realize that I'm pushing the conservation too far and I actually kill the product and try and bring in a new product. And his way of killing the product is to reduce the number of people on it, reduce the focus on it and take the best of this guys and focus on a new product. And it goes through that adaptive chain cycle more rapidly so that they don't have to face a catastrophic failure, they go through the cycle more smoothly. And I thought that was very interesting in terms of how this person was looking at it. Yeah, but it's hard to do if you have a product that currently has $15 billion in revenue. And I think that's the point he was trying to make is you've already pushed the conservation too far and that makes you vulnerable to having a catastrophic failure if you had a lot of smaller products making in the sum of that kind of money then as a company you've hedged your risk and you have better chances of sustaining longer. Right. I'm wondering if agile thinking has weaved in some of these risk mitigation part and I think you've talked a little bit about how do leaders look at risk and do you wanna throw a little bit more light on risk management in general and what's your advice? Well, I think there's a lot of risk that agile mitigates. One of the things, I don't know that I have much to add to the risk management arena other than one of the things I think is really important, particularly early in agile projects is that we talk about delivering the things of highest value early in an agile project. But I also think there are situations where you wanna get rid of the high risk first. And so particularly during the first, say quarter of an agile project, you ought to be as focused on risk mitigation as on value delivery, particularly if you're doing something new for the first time. So I may break it up into a few phases. I even talk about having a concept phase where it's really a proof of concept and the reason you do it is to drive out risks. So I think this whole idea of making risk management an integral part of the project and what you do on the project is really important. I think there's a whole risk management area in project management, but I think too often people say, well, here's a list of the risks over here, but they really don't do much about it. They don't try to mitigate those risks. They just sort of put them up on the end. You know, I've got my risk list and I'm done, but I think if you integrate that risk list into, okay, how am I gonna mitigate those risks? It's really important. So one of the problems with traditional waterfall methodologies is it assumed that the highest risk item was defining requirements because you do it first, right? And you get all the requirements defined and once I get all the requirements defined, that takes all the risk out of it. Wrong because the highest risk may actually be in a technology stack that I've never used before and I can't actually do the kinds of things that I wanna do from a technology standpoint. So I've spent all this time doing requirements, thinking I was mitigating the risk and I really wasn't. Whereas if I do agile lean startup kinds of things, I'm trying something out, I'm going to end of job, I'm testing it with the customer, I'm testing not only the requirements, but the design and the implementation all at the same time and so I'm mitigating a lot of those risks as I move forward. So I think that's one of the things about agile that can really help in mitigating a lot of different kinds of risks early on. Agile raises some other risks. For example, the risk of oscillation. I used to say that there's a big difference between oscillation and iteration. Oscillation is just going back and forth and not making any forward progress and that's one of the risks in agile, particularly if you spend too much time looking at it from iteration to iteration and you don't take enough time, really look at the overall program or the overall product. So that would just be what I would add to the risk equation. All right, I think that's beautiful. One last question, Jim, I think we have like last four minutes left and we'll try and wrap it up. I wouldn't keep you too long up. I know it's late for you and I appreciate that. So basically, where would you like the agile community going forward? Where would you envision? What would be your personal objective where the agile community should head? What's your take on that? Well, I just think if you look at movements in software or in business over the last 20 years or 25 years or something like that, the agile movement is now 12 to 14 years old depending on where you kind of start the timeframe. So that's a pretty long time. So I think it has stood the test of time and I think what we need to do is to keep innovating in ways that, you know, I don't know exactly what's gonna come along next but we've had lean startup, we've had Kanban, we've had some other things that, you know, we've combined some of the stuff from lean into agile and so there are a lot of kind of innovative, well, continuous delivery, continuous discovery, some UX kinds of things. So we're kind of continually sort of pushing the limits and innovating and I think it's really important that we do that, that we look at new things so that the agile movement doesn't become static and so far that's been the case. And I think what that also means is that, oh, there've been disagreements, will I say, between the agile movement and the Kanban movement or the agile movement and the lean movement and I think the similarities and the directions that we're going and the things that we're trying to do are more similar than they are dissimilar and that we ought to embrace those similarities just like the original Manifesto people did back in 2001, right? We came together and really focused on the similarities, not the differences in the different methodology. So I think that's one and I think the second one is again to move into this idea of agile, adaptive, flexible, responsive kinds of things, moving them into a management arena, into an organizational arena, not just a software development arena. So those would be the two kind of areas that I would think about. Great, great. Personally, I see that when the original movement had started, a lot of problems existed. The bottleneck really existed in the delivery side of things and I think agile kind of focused on the delivery side of things. Once we got that under the belt, we realized that no longer that's the bottleneck, the bottleneck has moved in other places and we started spreading out, trying to address other issues because this was no longer an issue. We figured out a fairly decent way of delivering stuff but when it came to UX, for example, that was something that we had not focused much back then. So we kind of tried to bring UX into it and we started realizing that business involvement in that sense or discovering what needs to be built and that's where I think the lean startup kind of tries to address that. The whole delivery cycle, people were doing agile, they were iterating and they were producing potentially shippable stuff but it was just getting stacked up and the continuous delivery movement kind of tried to address that. So I think what we, in my opinion, we're seeing is that we started at the core and we're spreading out because the bottlenecks have moved out and the agile movement is constantly trying to innovate and trying to push the bottlenecks out of the whole ecosystem if you will. Cool, all right Jim, I think it was fantastic talking to you. I at least had a very good interaction with you asking at least some of my questions and I think people on the webinar also had an opportunity to ask and we really appreciate your time spending with us and we hope that we can bring you to India at some point. Okay, and have a good conference. All right, thank you, Jim, you have a good night. Bye bye. Bye.