 Typically in these talks, we usually say put your phones away and that kind of thing. No, I don't want to do that. I want to actually have you bring those phones up and log in if you don't mind to menti.com. Once you log in there, there's a code that you'll be given or you should also type in and that code is 771616. And just tell me what your first thoughts are when you think of the word or the words agile transformation. There's a word cloud that's being formed as we speak. There's no profanity filter on this one. So be nice. There could be some awkward moments if people say what they really feel sometimes. So I just want to see what we see so far. We say adopt to customer centric, get here, here. Mindset change seems to be one of those things that come up a lot. Yeah, I would definitely agree with that. Chaos. Some people said chaos. I can't disagree with that either. And adapt. Simple. Simple. When you think about agile transformation, you think of simple. All right. I want to talk to you afterwards. That's great. I'd love to hear how you came to that. Learning organization. I love that. Mental barrier. Terrible. So now the honesty comes over. Yeah, this is nice. Terrible. Some people are saying terrible. People changing culture. Get the basics right. Flexible. Mental barrier. A lot of people are saying that. The slides will be available to you so you can see some of these results as well. But this is something that, you know, you're not the first people to say this. When it comes to agile transformation, it's a messy subject. It really is. This is one of those things that a lot of people are talking about this. But who's actually doing it right? And what does right even mean? It's very difficult to say. So this is kind of in my life's work. In the last 10 years, this is what I've been doing. Doing large organizations to work in more agile ways. Did this at Nokia. Did it at Intel. Did it at McAfee. A couple of the smaller organizations and I had some great successes. I'm very proud of those and I had some spectacular failures. But I learned a lot along the way and I want to share with you some of those things. And what I'd like to do is not focus just on the negative stuff. It's so easy to do that to just say, hey, here are all the things that go wrong. What I'd like to do in this talk is actually talk about the things that show that you're doing something right. What does it mean when you're doing an agile transformation? What are the things you can look at? What are the objective signs that tells you that you're on the right path? That's what I'd like to talk about today. So there's seven signs that I've seen. I know that's a little bit clickbaity. But there are seven things that I've seen consistently among the organizations that do this right and make a real change. What I'd like to do today is to share those with you and invite you to look at your own organization, look at your own teams, look at your own programs and ask yourself, am I seeing that in my organization? If I'm not, what's going on? Ask those questions because I think that's very healthy. All right, there's a book out and you have to say that so you can go to the bookstore and get that as well. All right, so why are we doing this? There is something very real about agile transformations. The thing is, we know that agile started in software development, or at least that's where it originates. The cost of change in software is so much smaller than in most other project management kind of things in terms of other industries. So it's natural that it started there. But what we're starting to see now is that this is now a business thing. I mean, really look at the world that we live in. The whole rate of change is accelerating, right? We have, well, climate change affecting things in ways we couldn't have predicted. We have all these upstarts coming up and completely demolishing existing industries. There's no barriers of entry anymore. And of course, we have this orange-hued dude in Washington that makes all these policies that just pulls everything off and suddenly we've got to deal with this thing. And what is it now? Brexit? Is it 10 days away? I think they're going to probably postpone it. But you know what I'm saying? There's things happening now that we couldn't possibly have predicted. And the world of business is changing dramatically, which means that the way we used to work is no longer sufficient. Really, if it ever was, it used to be a time where we can set up these barriers and not be so responsive to change and still be okay. That is no longer the case. So this is the world of Volca. All of you have heard of Volca, right? Volatility, uncertainty, complexity, ambiguity. It's a world of change that we live in that is impossible to predict. Having a five-year plan no longer makes sense if it ever did. It's not a clear linear relationship between cause and effect. These things are now everywhere. You have to be able to inspect and adapt. You have to be able to recover faster. And the whole idea of creating a robust organization that never fails simply doesn't work. What's happening is that our executives are recognizing this. Used to be that Agile was a software thing, right? Used to be one of those, well, I mean this in the nicest way. It used to be a propeller head kind of thing. Used to be a nerdy thing. It's no longer the case. These are discussions they have in the executive suites right now. They recognize that there's no sustainable competitive advantage. You heard this that many times, I'm sure. But the average age on the S&P 500, the companies that are on the S&P 500, used to be 58 years. Now it's 12. So these organizations are younger because they're going out of business, the old ones. They don't stay for generations anymore. They're being disrupted. Change is not optional. This is not a cool thing. It's not one of those things that if I'm not Agile, I'm not cool. If I'm not Agile, I might not survive. That's how fundamental this is. And what's starting to happen is that executives are recognizing that this is one of their top priorities. There was a McKinsey study. This was last year. They asked all their top clients, their executives, and they asked them, what are the top three things that keep you up at night? The top three things. And 90% of the executives there had business agility or the ability to change quickly as one of their top three. So that tells you that this is something that's really real. Now, despite all this, you know what? Some of these organizations are doing it right, and they're grading some really great results. Some of these organizations are looking at the benefits of business agility, and they're getting very tangible, very real business results out of it. So this is not vapor. This is very much real, faster execution. Have you guys heard of a company called Here? It's a navigation company used to be called Navtech. I worked there. We were able to go from a life cycle of 36 months down to six weeks. I mean, can you just imagine what that means for a customer? When you go from 36 months of having any contact to six weeks, that is huge. Agility made us do that. Increased customer focus. There was a talk yesterday from a gentleman, or two gentlemen, from ING. One of the things they did on really well, customer focus. Customer focus has gone up, and what that did was increased customer retention, 30%, that's what I've heard, 30% increased customer retention, that has a direct impact on the bottom line. This is because of their embracing business agility. Do more of the right things. Have you ever heard of a company called Equinor? Some people have heard of Equinor. It used to be called Statoil. It was renamed in May. It's actually Scandinavia's biggest company. And that company has a stat that I think is just amazing. It took me a while to sort of put my head around it. In the next two years, that company now is projected to make as much profits as they made in the previous 17 years combined. In the next two years, they're expected to make the same profits as they did in the previous 17 combined. Can you just imagine that? The reason for this is that they do more of the right things, and less of the things that aren't quite so right. They looked at cost of delay, and we'll talk about that later. In Nokia, hey, anyone had a Nokia phone before? Anyone has a certain affinity to the Nokia brand? I used to work for Nokia. I love that brand. A lot of people say, oh, you know, it's a failed company. Oh, hey, that's not the case. Have you heard of 5G? 5G is going to revolutionize how we talk to each other, how we connect people. One of the top leaders in that particular space with Ericsson is Nokia. And they keep innovating. They used to be a rubber company. Now they are a 5G leader. Part of what they did, which was one of the really huge challenges they had, was that as their brand went down, they were starting to lose their best people. To Google, to Facebook, to those kind of players. What did they do? They became more humane. They started embracing agility to actually increase employee retention. Very valid. And we know how much employee retention costs. Once you lose good people, very expensive to get them back. So there's some really good situations all over the world of companies doing this right and getting real business results out of it. This is why this is so popular. But there's also a lot of failures. Let's not kid ourselves. So I want to ask you now again, membermenti.com. Go to menti.com. I have a little list of what I've seen as the biggest ones. Vote on what you believe is the biggest reasons we fail in terms of agile transformations. I'm curious to see what you think. I have seen my share, and I'll share what I've seen. But I want to hear what your opinions are. Why do agile transformations fail? 94, 95, 55. That's the code. Just type it in, vote on what you think it is, and then we'll like to see what happens. Poor coaching, lack of leadership commitment. Ooh, that's the first one that comes up here. Unclear purpose, culture clash. I bet you that's what's going to grow quite a bit. Let's see who's going to win here. Looks like there's a race. Poor coaching. Yeah, that's one of those things that's happening now. Being a coach, being a scrum master, being someone who can be a change leader is a very attractive job out there. I read a recent stats in Silicon Valley. There's now four openings for any qualified agile coach and scrum master out there. So it's a very attractive job. Lack of leadership commitment seems to be winning here. Implementing a framework is getting some traction. Thank you for doing this. So I do this talk in a couple of different scenarios. It's interesting to see what people think. It seems to me that lack of leadership commitment is winning. And you know what? I totally agree with you. When I look at the key reasons that I've seen, this is number one, lack of executive commitment and support. If you don't have that, this is going to be incredibly difficult, if not impossible. This is a transformation. It changes how we work. It changes who we work for and how we recruit people, how we reward people, the processes we use, the culture we have. All these things change. It needs executive support. And I'm not talking VP, I'm talking CEO. Honestly, if you want to have transformation, you need that. Believing we're done, I see this all the time and this is sort of ironic because when you start embracing a more agile way of working, you're going to see benefits pretty quickly. There's simple tweaks we can do to dysfunctional organizations that would very quickly see huge benefits. I was in Todd Liddell's talk yesterday, optimizing for flow. If you start doing some flow optimizations and looking at your value stream, just visualizing it, making tiny changes alone will make a big difference. But the problem is, once you do that, you can't stop. That happens very often. Companies say, oh, look at this, we were able to improve our speed to market. We're done, we're agile. Let's go home, everybody, and go back to waterfall. That's what happens. This is something that we don't quit. Agile is not something that you become. It's something you become more of. It's a continuous improvement process. Number three, failure to show meaningful progress. We don't do agile. We don't try to embrace business agility because we're trying to embrace business agility. We're doing it because we're solving a business problem, right? That's why we do this. Show that. Make sure that you have metrics. Make sure that you show progress that directly show how we are solving or not solving the problem we're trying to do. And if we're not solving it, if we're not making progress, let's inspect and adapt and change it. Show meaningful progress towards the problem we're trying to solve. That's number three. If you don't do that, typical failure patterns. But this was supposed to be a positive talk and it's going to be. So what we're gonna talk about are the seven signs that show you that you are on the right path. So seven things that when you hear these now, you can say, yep, I see that in my organization. Or you can say, nope, this is not gonna work. You can see very clearly that you're not. So let's start with number one. I always ask executives this question. Would you rather be right or do you wanna be successful? Is an incredibly important question. You can't always be both. And the way that the executives answer this question is critical to success in business agility. Let me give you an example. And I felt this very much real myself. Stephen Elop was the CEO of Nokia from 2010 to 2014. I worked with him directly as part of the Nokia builders program, which was one of the programs we had as we were doing the agile transformation. Now, you know the story of Nokia, right? We had over 50% market share at one point. What's starting to happen is that this fruit company in Cupertino came up and started creating these devices that were very different, had a different operating system. We were on something called Symbion, if you can remember that. Okay, fair. Stephen Elop gets in, he just brought in, and we get rid of Symbion and we go for Windows Phone. Now, Windows Phone was a nice operating system. It had nice MPS scores. People liked interacting with it, but it had one major flaw. It didn't have apps. And that's pretty important if you're a smartphone. I mean, he had some apps, but it didn't have Instagram, for instance. And that tends to be kind of important if you're looking for a smartphone. It didn't have the Bank of America app. Like, simple things like that were simply not in that operating system. And this was one of those things which you can't just simply fix that because this is something that you can't say to a developer from another company, develop this thing now because we need it on our platform. Well, they will say, you know what? We got Android, we got iOS. We don't want to develop for Windows Phone. Nobody uses it. So it was really rough. Now, Android kept getting traction. iOS kept getting traction. Of course, we couldn't jump to iOS for natural reasons, but Android was an option. And as we were getting the data coming in, we were talking to Stephen about this because he said, hey, let's have an open conversation. And we said, you know what, Stephen? We're not getting any market share here. We're starting to lose. Should we change our strategy? Should we maybe think of Android instead of Windows Phone? And he said, nope, we're staying the course. We're burning the platform. We're staying the course. And he kept going that way until Nokia ultimately was sold to Microsoft. You've seen the story. It went from 51% market share to 2% in about three years. An amazing failure. It was not because we didn't have the data. It was not because we weren't agile. It was not because we didn't have the quality. Nokia phones were among the best phones you could have. You could have a bulldozer drive over those phones and they would still work. But we didn't have the ecosystem. And when we get the data, when we had the chance to inspect, we didn't adapt and it was not because we couldn't. It's because we wouldn't. Our executive wanted to be right. Now, there's a post script to this. Later on we found out that there was a clause in his contract that told him and meant to him that if he sold Nokia, he would get a one-time payment of $25 million. Yeah, this is not televised, right? But that's what happened. So maybe he was successful, but certainly not for Nokia. Contrast this with Donna Potts-McKinsey. Donna Potts-McKinsey was the HR director of here, of NAVTEK, which used to be here. We were doing our transformation there. So this is back in 2010, 2011. And we're looking at this and we're looking at the changes we're doing. I'm working with her directly and she's saying, Jorgen, I am terrified. I was like, why are you terrified, Donna? She's saying, well, if we're doing this transformation and we're truly changing everything, that means we have to change the roles. We have to change the role descriptions, the role portraits, the role paths, the compensation schemes, how to reward people, how to recruit. I don't know what to say. And now I'm being asked to stand in front of 200 people and tell them what my HR agile strategy is. What do I do? I told her, Donna, be honest with them. Tell them how you feel. Tell them this is something that's difficult but that you're gonna get through this together but you don't know all the answers. And that's exactly what she did. She stood that, an HR director in front of all these people in this town hall that we had on the 17th floor on the Boeing building in Chicago. And she said, you know, we're gonna get through this together. I don't know exactly how we're gonna get there. And I know that sounds weird coming from an HR leader but I am behind you and I'm gonna learn along the way and we're gonna be an agile organization. You got, I got your back. And that meant so much because those people, I promise you, they were feeling the exact same way. They didn't know what it meant to be a scrum master or to work in an agile environment. These were all new things. To hear a leader say the same thing meant a lot. She was committed to be being successful, not to be right. So that humbleness is important. All right, distributing responsibility. This is about accountability and responsibility but also incentives. This is one of those things that we do as organizations that I think can be so incredibly harmful. I was talking to an executive at a major energy company, let's get an AVS biggest, three months ago and he was telling me, hey, Jorgen, I hear what you're talking about. Optimizing for flow, making sure that we increase the speed it takes across all our organizations. It makes total sense, I get it. But I'm not sure what you're asking me here. I'm not sure if you're realizing what this means. I said, well, tell me, what's wrong? Well, the way things work is that we're distributed by sectors. And in my sector right now, I know that if I help my colleague over here and give her some more resources right now, we could get something out the door that's more valuable for our company. But if I do that, I will lose my bonus. And that's 25% of my salary. Because I have an annual goal that I need to meet. That means that I have to optimize for my sector. And if I do anything to stop that, for the better of the company, I myself will take a 25% hit. That's a pretty big ask. And you know what? I don't think that's unfair to ask that question. You know, we wanna be more agile, but is it fair that people take a 25% pay cut to do that? I don't think so. So this is us, as organizations, we need to make sure we change the way we distribute that responsibility. We need to make sure that we don't unintentionally harm people who try to optimize for the whole. I see that happen all the time. You probably see it in your teams as well. All right, number three, aiming for good enough certainty. This one is tricky. This goes to the idea that the time it takes to make a decision, the time it takes for us to be certain, is sometimes very, very, very expensive. This dude, he's been in the news lately for various reasons. Let's not talk about the reasons for that. But I love this quote from him. This is from one of his shareholder letters. And he says here, decisions should be made with about 70% of the information you wish you had. If you wait for 90%, you're too slow. And he's totally right. The cost of delay, the cost of waiting to make a decision is more expensive than recovering from a mistake later on. That's exactly right. In an environment that we work in now, where there's so much uncertainty, you will never get to 100% certainty. If anything is even remotely innovative, you will never be completely sure. But all the time you spend trying to analyze, trying to get everything right, that time is very valuable. And that's exactly what you're gonna lose if you try to get everything right. So look at yourself, look at your organization and ask yourself, how comfortable are we with good enough certainty? How comfortable are we understanding that we don't get it all right at once and that we figure it out along the way? Number four, appreciating the importance of doing less work at once. This one is a common problem, maybe one of the most common I see when I go to enterprise organizations. This is the importance of organizational whip. Work in progress, doing too much at once. Two things there that really speak to me is Little's Law and Kingman's Formula. Kingman's Formula, everyone knows Little's Law at this point, I'm sure. If you think about queuing theory, we think about work in progress, time cycle time, in terms of throughput, but then we also think about the implications of environments of high levels of uncertainty. What Kingman showed us was that if you are in environments of large amounts of certainty, if you increase utilization rates, the wait time goes up super linearly. If we go from 90% to 95% of utilization rates going up, wait times double. If you go up another two and a half percent, wait times double again. So you understand what's happening here. Once you get to a high utilization rates between 80 and 95%, utilization rates go up and wait times quadruple and then more some. Have you ever had a computer with a CPU around 95% utilization? Have you looked at what happens to that computer? It just shuts down, right? I mean, you can't do anything. Control, I'll delete. You're looking all that stuff. You look at those graphs. There's nothing you can do. This happens at the organizational level also. When you do too many things at once, you simply can't get anything done because everyone's task switching, everything is busy. We're doing failure demand type work. We're not focusing. Steve Jobs, who's not a typical agile dude in many ways, he was really good at this. He knew how to focus. What he would do every year, he would say, all right, I'm inviting my top 100 executives to an offsite retreat. And all we're gonna talk about are the top 10 things we're gonna do for the next year. And you can imagine how that went. They were in a room, they were duking it out, they were fighting, there was testosterone everywhere. And ultimately, they ended up with 10 things. And then Steve Jobs will come up and say, all right, we're scrapping the bottoms of it. Three things, that's what we're doing. That's focus. Ask yourself that. Are we doing this in our organization? Are we focusing on what's really important? And here's the other side of that equation. So you have to understand not to do too much work at once, but then you also have to understand what you're not doing. How do you understand that? Well, you have to understand prioritization. And the best way I know how to do that is through economic sensibilities. Look at the financial results of making these decisions. And cost of delay is an excellent way to do that. Cost of delay was popularized by Don Reinertson. He's a giant in our field. I recommend you go and look at his books, Principles of Product Development Flow. Excellent book, a little bit dense, but excellent book. What he's talking about is the impact of time to life cycle profits, which is cost of delay. Now, why is that so important? Well, we could talk about calculating it later on, but this is why this is so important. At several of the organizations I work with right now, I've mapped out the different projects and initiatives they're working on. And we looked at an estimation of the cost of delay. And it looks kind of like this. It's a Pareto chart. And what does that chart tell us? It tells us that 80% of the cost of delay is focused on about 20% of the projects. But what do you think is happening? We are fighting for resources among all of these projects. And why and how do we operate and how do we prioritize those projects? Well, usually it's because of some VP or some executive or someone with a loud voice that says, Brian wanted this, or this is important because I said so. But it's not based on economic sensitivities. It's not based on simple prioritization based on economic value. So if we do this, what we will find out is that there's some of our projects that are much, much more important than others. And the more we can divert our resources towards that and not the others, and then decrease the cost of delay because economic sensibilities, you're on the right path towards agility. Very important one, this one. All right, this is hard for a lot of people. Learning to let go of the illusion of control. We love this feeling that we can control everything. We are masters of our domain. We love that idea. But the idea is we can't really build organizations that are robust to the point that it can never fail. That is impossible. In fact, recovering from failure is more important. You've probably heard of this concept before, chaos monkey, Netflix is famous for this. I love what they're doing here. What Netflix realized, and many organizations that are using the same type of methodology is that the point here is not to not fail. In fact, we will plan to fail. We will know that failure is inevitable. But the idea here is to recover quickly. Is to make ourselves resilient. So that when we fail, not if, but when we fail, we recover without serious incident. Chaos monkey is about that. It's about essentially creating errors, creating outages in strategic places to see how quickly we can recover from that intentionally. Does that stress out some people? Sure. But what do you think that do to their mindset? What do you think that do to the way they're always prepared to recover? It's very, very powerful. Chaos monkey. Okay, the last one. And this is one of my heroes, Russell Ackoff, recognizing that a system is a product of its interactions. What he was able to realize is that when it comes to a system, which is what an organization is, a complex adaptive system, we're optimizing for flow, we're optimizing for how we work together. It's really the interfaces between the different components in that system that matters. That's the product of that system. It's the interactions, not the individual parts themselves. The best way I can illustrate this is from one of my own projects. This is a typical value stream on one of my projects. And what I did in here was to show you when we're actually adding value to anything and when we're actually wasting time. And what you see here, it's a little bit difficult to see, but in this little part in the middle there is what we call agile efforts. This is when we're actually working as teams. This is when dev, test, operations, you name it, are all working together. There's not a lot of waste right there. We're doing pretty good. But then if you look to the left and to the right, there is a lot of waste. What do you think that does to cause a delay? You think of all those red dots and you summarize this at the end, you see that it takes us about 43 weeks before we get to production and before we even get any type of interaction with the customer. Not very agile. Most of the agile transformations I talked to and I work with are kind of looking like this. There's tons of work happening in the product development and product management space. We're quite agile in that particular area. But if you talk to people in, say, marketing or sales or if you're going anywhere on the left or on the right, people are like, agile, what's that? Yeah, I heard about it. But there's no consciousness about it. We haven't talked about it as a system. But ultimately, that is what value is. It's an end-to-end situation here. We're talking about when a need is discovered until a need is fulfilled. That's typically not happening. Akav understood this back in the 60s. We still haven't gotten this from a business agility perspective. So that is one of the things we need to know. All right, so you heard about the seven things. Now I'd like you to go to Menti again. Type in menti.com. Look at the code 881909. 881909. I'd like for you to tell me which of these are the least likely to happen in your organization. Be honest now. Look at these seven and ask yourself, all right, we see the signs now. Which are the least likely to happen? I'm curious. I've done this talk a couple of times and I've seen some really interesting results. I'd like to see what you see. Very few organizations are doing all of these. Some of them, they're doing it really well. I have to put Amazon very high on that list. You might be able to select two. Yeah, you might be able to inspect and adapt, as they say. Like the executive that we talked to when, yeah, you could distribute your percentage. Like where do you think is the most important in your organization? And then we'll see what that turns into. Oh, here's a couple. Understanding the economics of our decisions, yes. Cost of delay. This is one of those things that's gonna, when we talk about what an agile manager does. People talk about management and agile, how does this change? This is one of those things where agile managers are gonna have to change the way they work. Understanding the impact of delay. Understanding the economic decisions and prioritization. Importance of doing less work at once. Oh, we see it, okay. All right, we can see that learning to let go of control is looking pretty good, yes. Lot of managers, that's how they got their jobs, right? They were the ones who controlled everything and now they have to sort of step back. That's really difficult to see that. Distributing responsibility and incentives. I see that at the team level as well. Do you wanna be right or successful? This is one of those where, I don't wanna be unfair to executives either. You know, it's easy for us to say, oh, you know, do you wanna be right or successful? Why bad executives just wanna be right? Sometimes they are not empowered to be right either. They may have a board of directors where they have been given marching orders. So they might not have that flexibility either. So we should be fair to them in that sense. Learning to let go of control, yes. Yeah, these two things, learning to let go of control and understanding of decisions, the economics of your decisions, probably the two things that I've seen most. Look for that in your organizations. If you have those kind of things, that alone will make a big difference. If there's anything you wanna start with, limit whip. That would be my number one advice. Start limiting whip. It will make a huge difference to your productivity. All right. So what I think, I hope, will be clear, is that this is not something you do at the product management level. This is not something you do at the team level. This is an organizational change. And that means you have to change the entire organization. It's a holistic view of transformation that we're looking at here. It means you have to change your technology. When we talk about technology, I mean the tools, the techniques, the methods, anything you do to get things done faster and quicker. It could be scrum. It could be combine. I view combine as a technology. I know some people will probably argue with me on this, but in my definition here, I'm talking of things you can do to get things done quicker and faster and easier. JIRA could be a technology. The thing about these things is that they're very visible. Usually this is where people start and end. And that would be a mistake. You need to also think about your org design. How do people work together? How do we collaborate? What's our collaboration space? Do we focus? Can we collaborate? Can we combine both? Can we give focus space when we need to? Can we be context sensitive? How do we organize ourselves? How do we organize ourselves across our value stream? People, how do we reward people? What kind of people do we recruit? What kind of people do we hire? And also, what kind of people do we let go of? That's part of this too. There's not everyone's gonna make this journey. Leadership, what kind of language does leadership use? What about growth mindset? Are we allowed to fail? Are we allowed to learn along the way? Are we not having to always be right? And lastly, culture, which affects all of these interchangeably. A learning organization. That's essentially what embracing agility is. Learning and always inspecting a doctrine along the way. The three parting thoughts I'd like to leave you with. Number one, which I think should be clear from this talk, unlocking agility requires significant investments in organizational change. Know why you're going agile. Don't do this because your competition does it. Don't do it because you have some certification. Do it because you're solving a real problem. Understand the why. Stating that everything agile is great and everything great is agile is not very useful. You have to recognize the environment you're in and there are certain environments where agile isn't gonna give you all the answers. If you are in a non-vocal environment, I wouldn't necessarily say agile ways of working is your preferred choice. It's not necessarily gonna be the most cost-effective way to work. Is it gonna have you deliver value faster? Yes. Is it gonna help you be more adaptive? Yes. But can you squeeze costs out of everything? Are you gonna decrease variability in an agile way? Probably not. Part of what's happening, of course, is that the world is increasingly vocal. That's why business agility is becoming more and more important. But understand that. And understand that the operational strategy needs to support your business strategy. And lastly, agile is not something you become. It's something you become more of. This is a journey. This is something that you continuously do and you never quit. It's a lifestyle, not a diet. Here's some books that I recommend. If you look at, and yes, I did put my own book on there. So I know that's kind of bad. But there's a lot of resources in that book. I put Reinherson on there. There's Taleb, Nassim Taleb. Excellent book, if you wanna look at. Things like anti-fragility. There's a lot of great books. And I think these slides will be available to everyone so you can look at them there as well. I did talk to my publisher, and for real, 45% off they gave you until the end of this month. If you are looking to buy my book, you can get it right now using the called Agile India. That's all I had, but what I'd like to do is actually hand out some free books. And I'll give the first free book to the person with the first question. Okay. You... Okay, now you gotta have a question. The parting thoughts? Yeah, there's many more, but those are the top three, yeah. This relates to, yeah, this relates to the first one you did, the lack of purpose and the leadership. Of the executive support and commitment, yes, yes. The question is, in your experience, dealing with executives and the senior management, is lack of executive support because they themselves don't have a clarity of the vision? Or is it, I mean, what are some of the factors why the commitment is not there? Yeah, so did you hear what he asked? Yeah, what's some of the reasons why we don't have that executive commitment? You know, to me it comes back to the problem we're trying to solve. When I have been able to do this successfully is when the agile transformation is a result of solving a very compelling, important business problem. I don't think executives wake up in the morning and say, I wanna do an agile transformation. I just don't think that's top of mind. But they are worried about the things that we saw earlier, the VUCA stuff, organizations changing faster, competition intensifying, those things they care about. Now, if they can see that an agile way of working might help with that problem, then you'll get their commitment. That's what's been happening for me. When I've been able to do this successfully is when they see that an agile transformation is a way to do that. And why that helps is because the people you have on your team now are the head of HR, the head of finance, the head of marketing, not just the head of engineering. Because that's typically what happens and that's not enough. You need the entire holistic end-to-end organization to be a part of this. So, again, goes back to the business problem. You guys are asking good questions, so I'll give up. Oh, all right. You talked about lack of sense of purpose on why are we doing what are we doing. But the beginning slide said lack of leadership, alignment, or that itself is one of the failing reasons on why are we not able to unlock agility. So I see both in many organizations where there is a lack of purpose and even if there is a purpose, there is a lack of alignment at the leadership level. So I was just curious on why that was not overly purpose over leadership alignment, beginning with why. So just curious on is there a rationale behind why you had put in the leadership over the purpose in the initial slides? Well, so what I was trying to talk about here is how we make agile transformation succeed. And the lack of executive support is the number one reason it doesn't succeed. So if you don't have executive support, that's not gonna help. When you talk about purpose, if you don't have organizational purpose, that goes way beyond an agile transformation. You're gonna have, I mean, you can have a banana transformation if you like. It's not gonna work if you don't have a purpose. I mean, you need to have a vision. Those are things, though, that business executives think about as separate from the agile transformation. The agile transformation is the means to an end. But if you don't have a purpose, I mean, you have bigger problems. So an agile transformation isn't necessarily gonna help you with that. So, yeah, yeah? Right. Yes, the very thought of giving up control is very scary for a lot of, I totally agree. Yes, you can look her up on LinkedIn. HR director, can you just dwell a bit more about how did she go about handling it? Because on the ground, we tell team and we encourage team to do teamwork and things like that. But on the other side, coming to the ground reality, we have people being measured on the number of tickets that you're selling. Yeah, great question. How did they deal it? Because this is what I encountered day in and day out. Yes. In all my coachings, I tell, but I'm having coffee that people ask this question to me, which I don't have an answer to. Did you hear? So I would want to hear your thoughts on that. This is perfect, yeah. So he's essentially asking, how did this happen, especially with Donna, the HR director, when we talk about making these changes, but yet on the ground floor, we're doing things that directly go against working in an agile way. We're being measured by the number of tickets we do and things like that. So that's exactly the point, because now suddenly Donna, the head of HR, who also influences how we reward and punish people, she now said, what can I do from an HR perspective to support a more agile way of working? And now suddenly these things are now being questioned. So yes, we got rid of that metric. We weren't looking at how many defects do you close. We didn't talk about that. One thing we did look at was how much time does it take us to close a ticket from end to end? It's not just one person now, it's the whole team. We're saying how does the team work together and collaborate so we have our lead time being reduced rather than just a person closing a ticket or even sometimes just opening a ticket just to close it so they can look better on their metrics. So basically, are you telling that you are measuring the teams as such, the appraisals, the hikes are at a team level? Are you talking about that language? Your metrics need to change. The metrics that we have right now are optimized for a very different way of working. If you don't change the metrics that you have currently, if you don't change the way you work, you're not gonna change the way you work. So you have to change these things also. That's why it helps to have HR and those other groups outside of IT help us. I'm gonna ask a question and then the person, the first person who answers that correctly will get the last book. What is the fourth value in the Agile Manifesto? Blurt it out. Responding to change over following a plan. Very nice. Thank you. All right, that's all I have. Thank you. I'm gonna be tastered if I stay longer. Thank you so much, guys. I really appreciate this. On a lighter note, I have an acronym for that. I want change requests. Individuals and interactions, working software, customer collaboration, responding to change. Remember I said. While there's no change request in an agile world. Change request, right? There's no change request in there. That's right. Thank you so much.