 And this is true whether you're talking about software. So let's do a quick show of hands. I'll cut back up here. Who here is a technologist, a developer, an architect, or in some way deeply involved in technology? Fantastic. Who here considers themselves to be a leader? Very good. Why would those technologists not bring their hands up? You're leaders, too. Aha, technology. I've been up here trying to get this to work. And it did. That was my backup slides if this didn't work. But this is now working, so I can use this. Fantastic. Certain uncertainty. So let me give you a little bit of history. Let's talk about why the hell we are here today. Over the last 30 years, a number of interesting things have occurred. And all the bad in the most part. Every age of companies has dropped by more than 50 years in the last decade. Since 1983, 57% of the 21% of the companies no longer exist. These are the companies that have gone bankrupt, that have gone through an acquisition. These are the companies who have just sort of faded significant significance. The largest companies in America no longer exist. And these aren't the oldest companies. This is yes, for every Kodak and for every Chrysler, there are 100 other organizations that were there and are now not. So business agility, this is the day. This is the track that we're talking about today. There's a context to this conversation. Some of you might have, Ashina, let me take a step backwards. What does business agility mean to you? I won't ask you to tell me, but just think about it. 10 seconds. What is business agility in your head? For some people, it's around product ownership. We're doing scrums. So business agility means we're going to get the business involved. That's a part of it. For others, it's about empowerment, about team and structure. Who here is sort of the Spotify model? There we go. So other people, it's more about leadership. It's more about the qualities of how leaders work. And for others, it's about taking agile, scrum and Kanban out of IT and applying it to other domains. Talent, HR, marketing. There is no definition of what business agility is. And to be honest, nor can there be. For my sins, I run the Business Agility Institute, which is a brand new organization. But before that, I've also put together the Business Agility Conference in New York. When I put on the conference, this was a community event. All of us were volunteers putting this together. And we had this idea, this goal, that let's bring all the Agilists together to talk about what business agility means and to come up with a definition. But as the conference got closer and closer, we realized that that was a foolish thing to do. Any definition that we took together, especially in a thing that is as formative a state as business agility, would it be so general as these two? Or would it be so specific as the alienates half of the community? All of us had to look. So instead, we decided not to do that. We had the conference and it was a success and we had some great talks. The staff was there. So what we then decided was, let's, we still need something. And this is the something that we came up with. This is what we call the domains of business agility. Or as I like to think of it, this is the do not forget this model. This is not a framework to tell you what to do or how to do it. It's just telling you things not to forget. You're going through an agile transformation. You're adopting scram, kambam, all right? You've watched Linda's great talks on experimentation or growth mindset. You've got all this in your head, but if you're gonna go through this change, if you want to be an adaptive future organization, don't forget, all right? So we put these domains in really four, so in three dimensions. Work, the ways of working, the ways of delivering and creating value. Connections, which is the relationships that exist within organizations. And mindset, culture. I'm gonna take some of these in turn and just explore them briefly with you and give you some examples of where organizations are taking them. Now, because we are in agile India, I'm not gonna spend too much time focusing on the agile part of it. I am presuming you know what agile is, the manifesto and all that history. Instead, we're gonna talk about the identity in the wider product context. That the host of the model is our customer. And we put the customer at the very center of the model because they don't exist anywhere else. As Steve Denning said in an earlier talk, I watched with his, right? Looking for org charts, the customer is not in your org chart. The customer is not in your organization. And yet they're the very purpose we exist. They're the why we are in business. For those of you who saw me speak last year, I talked a lot about outcomes and how to create outcomes and outcome profiles. And I said then, what I'll say now, you are not in business to make money. That is not your purpose. You have to make money. That's important. And it's a great quote by Frederick Lalu. Profit is like air. We do not breathe, sorry, we do not live to breathe, yet we do breathe in order to live. And that's true. You have a purpose in your organization. A doctor becomes a doctor to save lives, to heal the sick. And don't become a doctor to make money. Well, a good doctor doesn't anyway. Most of them. However, a doctor still needs to make money. They have to make money so they can pay their insurance, so they can feed their family so that they can continue to do their job. And this is true of your organization as well. Whether you are providing, who are the sponsors out there? Oil and gas, Agira, Agira consultancy, or in Latin consultancy. You're not in business to make money. You're in business to help people. You're in business to power the world. Pick your slogan of choice. But they have to be more than just buzzwords. These have to be the very KPIs or OKRs or outcome profiles that you exist with. Anyway, I'm rambling, so I apologize. But let's talk about how. If you want to be an agile organization, if you want your customer to be at the center of that model and this customer to be why you exist, you have to have trust. And trust is literally the point of, well, all of this. If you don't have trust, you will fail. Or at least you cannot be agile without trust. This is what we call a pyramid of trust, right? Let's say you're renovating your kitchen and you need a carpenter to come in, right? So I'm gonna come down and go, okay, I need a good carpenter. Who's a good carpenter? I read Yelp. Great, you've been recommending to me you're the best carpenter around. I bring you in. I'm sorry, I don't trust you. I have no trust in you. I might trust Google. I might trust Yelp and my friends who recommended you. But I don't trust you. That's reference trust. I trust the reference. We go up a level. Contract based trust. We agree on scope. We agree what you're gonna do. Fantastic. Now I don't still trust you but I trust the contract that we have. I cannot be agile with you if I trust the contract. It is very hard to write a contract in such a way that allows real agility. The real agility requires a level of trust. By the way, that's not saying that if I do trust you, we don't have a contract. We always have a contract but the form and the terms of the contracts will differ between an agile organization and one that is not. Now let's fast forward six months. You did a fantastic job on my kitchen. Great. Now I wanna do my bathroom. I'm not gonna go to Google. I'm not gonna go to my friend and ask for a recommendation. I'm gonna come to you because I trust you. And then something wonderful and a bit strange happens. I am able to change the conversation. If I don't trust you, I'm gonna ask the following question. How much will it cost? Because I don't trust you to answer any other question. But now that I trust you, I might change the conversation. I might change the question. I've got 10,000 the hollers. I've got 10,000 the hollers. What can you do with that? Now what about the power in that question? I have trust with you. I know, and you can break that trust, you can pull me off, right? But that's a risk that we take in any trust relationship. If a wife can definitely abuse the trust that I put in her, that doesn't mean I don't trust her. Oh, I've given up the black text. I've said what can you do with this? Are we gonna work together? We're gonna figure out based on what's possible and what's not possible and what's not. And we're gonna create something that is agile. And I'm talking about doing my bathroom. There's no software in that, unless you have a really fancy bathroom. So congratulations. We are now, I now have an agile relationship with a customer-vendor relationship, right? The customer's at the heart of the agility. It can only happen when the customer has trust with you. Understood? Now the top of the level is partnership. Now I'm not gonna enter into a joint venture with my plumber, right? It's just, it's paid, the metaphor breaks down at this point, right? But this is where we have shared outcomes, right? Rolls Royce, right? If you, Rolls Royce provides aeroplane engines, very big aeroplane engines, right? And in about the 50s, 70s, that's embarrassing, I forget exactly when, they came up with a funding model for their engines called Power By The Hour. And it's really fascinating because what happens is Rolls Royce will charge you for every hour that engine is in the sky. And they won't charge you if it's on the ground. It is the very definition of win-win. If the plane's in the sky, you're making money and I'm making money. If the plane's on the ground, I'm not making any money, but neither are you, right? So it's in our interest to have that plane in the sky. And we have a mutually beneficial, literal win-win relationship, right? That's what I mean by partnership. But let's go into sort of how. The customer is why. They are why you are in business, not money. And certainly not to grow market share, whatever your shareholders might think, but they're one business. Let's talk about your transformation. You're beginning an agile organization. Remember, this is don't forget model. These are things not to forget. Now the work that you mentioned, I'm gonna skip over pretty quickly because, again, this is an agile conference and this is the domain of agile. Technical agility. This is the domain of DevOps and XP. This is the, I am physically creating something of value. And I'm doing so in an agile way. Process agility. This is the domain of Scrum and Kanban. This is where we have a value stream. And that value stream generates, it's in the name, value. This is where organizations focus so much of their transformational energy, transforming process. That's fine if process is your constraining factor. I'll come to that in a second. The third domain under work is what we call enterprise agility and this is where it starts to get interesting because this is now at a much broader level. We are now talking about agility across the entire organization. We are talking about agility between finance and HR and sales and marketing and your PMO. It's looking at the broader value stream and all of the hand-offs and the pieces of the puzzle that go to making your organization work. Now, there's a concept which I talk about quite regularly. If you haven't read, there's a book by Ellie Goldratt called The Goal. In it, he talks about the theory of constraints. So allow me to very arrogantly introduce Evan's theory of agile constraints. An organization can only be as agile as it's least agile part. Let's go back 30 years. We're in the 1980s and 1990s. Where is the constraining factor for agility in your organization? We want to build a product, a software product. Take software. Who's constraining our agility? Why? It's a software team. Software team, it takes them two to three years to build a product. We want to make changes, it's slow, it's painful. So what do we do? The 80s, it's the 90s. We invent agile. Scrum, FD, Rad, Crystal Clear, you name the method we invented it. Fantastic. Now, fast forward, it's not about 10 years ago. We now have an engine that may make change in three to two weeks. Where's the constraining factor? Well, we still have to wait three months for a deployment window. So it doesn't matter how fast we can go, our consistency to agility in the market, certainly, is to deploy them. So what do we do? We invent DevOps, congratulations. We now have an engine, we create change every two weeks. We deploy change, what's Amazon's statistic, every 11.6 seconds. Where's the constraining factor today in your organization? Without knowing your organization, I will have to guess it's one of four places. It is either the PMO, it is finance, is HR, or it is legal, compliance, right? Last, yeah, okay, I have a hidden note. And in my experience, that tends to be where the constraint is these days. Which one depends on the organization in the bank, quite often, the legal and compliance constraints. But let's take HR as an example, right? You've got, I can make change every two weeks, I can release it every 11 seconds, but it takes me six to 12 weeks to recruit the people I need to even get started. It doesn't matter how agile I am. My recruitment process is my constraining factor to my agility in this organization right now. It doesn't matter how much scrum, or safe, or less, or kanban, or whatever, I put into my organization. Cause that's getting my process agility improved, but that is not where my constraining factor is. All right, I already touched on that. So let's go to connection. These are the relationships. Within the connections dimension, that's a hard thing to say. We have three domains, leadership agility, structural agility, and market agility. Leadership agility is the relationship that you have with authority in the organization. Structural agility is the relationship that you have with each other. And market agility is the relationship that you have with the wider, well, world, your supply chain. Remember, customers at the center, the market agility isn't necessarily the relationship you have with your customer, maybe with your end users, but it's also with your suppliers and your vendors. It's the entire supply chain that the market will operate within. Let's talk about leadership ability. I've got some interesting examples here, but I won't really go into them because I've already had the art for some fanatics stories, and you've got Steve Nicky, I'm not talking about the age of art, I'm talking about some stuff, I'll let them focus on leadership agility. But this is the domain of servant leadership. This is the domain of delegation. I don't mean delegating work, I mean delegating outcomes. Authority and accountability that go hand in hand. You need both. This is not delegating. Hey, I've got a piece of work for you. I need this report done by next Friday. Fantastic. That is delegation today, that is not leadership agility. Delegation in leadership agility is, we have to make sales. I give that to you. That's on you. How you do it. Maybe you create a report, maybe you do a presentation. Maybe you do song and dance. I have delegated the outcome, the business outcome to you. You are empowered, I hate the word, but you are empowered with the accountability, which is what literally delegation is, but also with the authority. It's on you to decide what you need to do. If you need to spend money, spend money. If you need to make something happen, make it happen. There are constraints, there are regulations. You don't have a free hand. Nobody has a free hand. Everyone has some level of constraints. But you do have autonomy. Within the constraints of the organization and the organizational processes and cliff limits and all those wonderful things that companies put into place, it's yours. I'm not gonna tell you what to do. I'm just gonna tell you why we need it. The how and the what is yours. That is leadership agility. Structural agility. This is kind of the big thing at the moment. Once upon a time, literally like four months ago, I was a consultant. What do management consultants like to do? Restructure. We love restructure. Why? Because it gives the perception of change. We shuffle a few people around. We've left the organization in a different configuration than we walked in and then we've walked out again. Now, a good management consultant that restructure will actually achieve something. Not always what was intended, but it will make some impact. So structural agility is getting a bit of a buzz at the moment because teal organization, Spotify model, half of you probably are starting to join squads and tribes now. Nothing wrong with that. It's just this, the active restructure is not structural agility. It's just the mechanism that one puts in place to achieve it. So what is structural agility? It's not just squads and tribes. It is about, let me answer that in two ways. Number one, we're talking about the characteristics of an astral organizational structure. And these are words you all know. Cross-functional teams. Nice and simple, right? Reduce, like, delegated accountability. Ownership. Wonderful, wonderful words. This is the characteristics, but structural agility means look beyond your existing interest models. Look, cross-functional teams does not mean we're gonna get the developers and the testers in the same team. Cross-functional teams mean we're going to put all of the skills necessary to achieve outcome in the same team together. Not outputs, but outcome, and that's critically important. So if a business outcome, if I require a recruiter, if I require an accountant, if I require a technical writer and a graphic designer to pick a hundred skills that you want, they are part of my, I will use the term squad, they are part of my team. Now, seven plus hundred plus two, we still believe that, small teams are better, but those can be the execution units. An outcome of value delivery team could be a hundred people, broken up into specific execution units, but that team has the accountability and the authority to deliver on the outcome. That is fundamentally what structural agility is. Now, characteristics. Sorry, actual examples of this. You've got the obvious one. Who here has read Reinventing Organizations by Frederick Lalou? Surprisingly few. For those of you who did not put your hand up, read the book. There's a whole bunch of problems with the book and it glosses over the downside of structural agility, of what he called a teal organization, but effectively the premise is there is an organizational model which he calls a teal organization, which is a network-based organization. The structure of the organization is such that teams and connections between teams form and reform, dynamic, all right? There are elements in the world. The great one is Morning Star. Morning Star is a blue collar, tomato processing factory in the United States. Raw tomatoes in the end, thin tomatoes in the end. There is no solid bear in that organized model. I'm sure in the back office there is, but that's not the purpose of the organization. This is an organization of thousands of blue collar workers and no managers, all right? The coordination is done organically by relationships between teams, networks, agreements in the supply chain, all right? I need, you need to give me this so I can give them this. The decisions around who to hire, who to fire, who get to pay rise. Decisions around which planned equipment needs to be upgraded, which needs to be repaired. That is made, and there's a lot of different processes they put in place to make this happen, but this is not made by a manager. This is made in the organization by the members of the organization, all right? They form committees, they form agreements, there are charters and patterns that make these decisions, but there is no, you have to be a manager or above to make that decision because there are no managers. There are other examples. Bertog, a healthcare organization in the Netherlands. It is run by the nurses, all right? Here's an interesting, sorry, just a side note. Here's a very interesting thing about structural agility. Organizations, and to Linda's point, this was not done with a scientific rigor, but organizations that run under many of these models will outperform organizations that do not, all right? There are some fairly decent studies that show that organizations that are perfectly driven will outperform organizations that are financially and revenue driven, and I used to work for IBM, so I can keep you on here when I'm coming back. Organizations that are driven by that agility that are able to opt quickly in the market, all right, for those that are not. Structural agility, and it doesn't have, I've been giving you the extreme cases, just come to it. In your organization, there is already an agile structure. It's just hidden inside your current hierarchy, hierarchical structure, all right? Think about the network that exists. Think about how many bosses you have. Think about how the relationship that you need to build in order to achieve something. Congratulations, that is your network organization. You've already found it. Now, do you wanna make it better? Bring it closer. Reduce those lines of communication. Either bring them physically into teams, all right? Reduce the lag in that communication channel. Make it faster, make it briefer, make it clearer, all right? That is how we get structural agility in an existing, very legacy hierarchical organization, or how we start, all right? We still need leadership agility. If you want business agility, all right? Restructuring to Spotify model is not gonna help, because you still need leadership agility. You still need the other forms of agility in there to help you. Does that make sense? Okay. The last one under the connections domain is the market agility. This is the agility that exists in your supply chain. So let me give you two examples. First of all, agile contracts. Who here is either a vendor, another organization, or works closely with vendors? Most of you. Who here has what you would consider to be agile contracts? One of you. It's fantastic, go and see how agile contracts are hard, because most contracts are, what do we do? Fixed time, fixed time, fixed price, all right? That is not an agile contract. There is no agility in that. But let's go back to trust, all right? I'm not gonna go purity in them because I don't trust you, all right? If I'm IBM, you don't trust me with a blank check. There has to be some commitments in that contract. So here's a suggestion. Agile contract 101, I could spend an entire 45 minutes on this, but I'm just gonna give you a quick answer right now. The simplest form, unless you wanna go purely with T&M, the simplest form of commitment-based contract for agile engagement is the following. Fixed price with commitments. Fixed price does not mean fixed scope. So it's gonna be a million dollars, and these are the commitments that we put into place in the terms of this contract. Number one, MVP. All right, now MVP means 20, 30% of the size of the contract, not 80, 90% of the size of the contract as I've seen many, many, many times. Commitment number two, quality. We guarantee a certain number level of defects in production, right? We will not commit to defects in tests. We wanna find defects in tests. So no measure should stop us from creating, finding and rectifying defects in tests. The measure should be in production, right? Mean time to resolution. How quickly will we fix the defect that we find, right? Now, do we use velocity as a commitment? No, congratulations. You've all at least passed that one. Velocity is a bad measure, except I can give you an example where velocity could be part of the good measure, right? So, the problem with velocity is it can be gained. But let's take another relative measure that we can use. We have story, velocity is the story point delivered per sprint, right? So, story point, it's a relative measure, right? This, harder than this. This is one, so this is a two. Value points. Value points. This is more valuable than this. This is a one, so this is a two. Who estimates the value points? I think it's the business, the product owner at best, sorry, at worst, the customer at best, right? So the customer estimates the value points and the team estimates the story points, bring them together. We call that ROI, right? How are we going in terms of delivering value per time? Highest value, lowest effort should theoretically be done first, all other things being equal and dependencies not being taken into account. If you want to put into your contract a throughput measure, we can use cycle time, by the way, that's another one. But if you wanna put a throughput measure, do an ROI measure, right? We guarantee a certain percentage of value to velocity ratio, right? Based on whatever the baselines are agreed on. And then, what happens if you exceed that ratio or under that ratio? We stop the contract. And you know what the great thing is? We want to stop the contract because the ROI has just gone negative, right? So that is the only way you can put velocity into the contract. So let's go about mindset. Let me just check my timing. I've got 15 minutes, fantastic. Mindset, three domains under mindset. Learning, collaboration, and ownership. A learning mindset, an organization. You have the master of this thing in the back of the room. She's the one who taught me about growth mindsets. I have literally no idea when, first, so you speak, probably about six years ago, right? Growth mindset is key, right? I will, as a cycle note, as a personal note, she has literally changed the way I raise my daughter. My daughter's five years old and she has changed how I teach. There we go. I've embarrassed her, fantastic. She has changed how I raise my daughter. Anyway, slide point. You need a learning organization. Now, learning organizations are for learning mindset. It's not just safe to fail. It's not just the culture of experimentation or trialing. That is a part of it, absolutely, but it is definitely not the totality. A learning mindset is also being able to understand your strengths and your weaknesses, right? There are some organizations when a team forms, everyone will say, hi, I'm Evan, right? This is my role on the team, and my biggest weakness is getting me to shut up. That's true, by the way. That is a learning organization, one that is willing to own up to weaknesses, own up to their strengths, and actually be willing to make an effort to improve on that. This is an organization of kaizen, of continuous improvement. This is an organization of the retrospective, right? These are all mechanisms that help us create a learning mindset, and you cannot have business agility unless you have it. I'll give you an example of where I've seen this really apply. It was a financial institution in Singapore, and they wanted a culture of safe to fail, and they tried a different thing. Because here's the problem with banks, you get what you measure, and what you measure in a bank, money. So people are incentivized to make money at all costs. And that has, if you look at what happened with Barclays, RBS, there have been some blatant abuses of that motivation. So, this organization was that. They said, we want to create a learning mindset. We can use those words, but that's what they were trying to do. They wanted to make it safe to fail. So, first things first, what did they do? The leaders tried to get the body safe to fail. They would talk about their failures. They would make it easy to have that conversation. But here's the secret, nobody likes to fail. You can talk about it if you like, but the more you enforce that conversation, the more someone's just gonna pull out a trite answer. Oh, I brought down the test system because my code didn't compile. I find that was a failure, but realistically, what did you learn? So they tried a few other things, but what they ended up settling on was exactly what I said before. You get the behavior that you measure. So what did they do? They put in place a failure KPI. Very interesting. The KPI went as follows, right? You must demonstrate that you have failed, and then obviously learned from that failure, at least once per quarter. Now, obviously, the level of the organization that you are in determined the size of the failure. A software developer is not going to bring the company to its knees, and at the same time, if the CEO said, I broke the build, we're gonna have a different conversation about failure. Why did the CEO touch on the build? Now, this changed the dynamic because no longer was it safe to fail, it was compulsory to fail, and I got asked one question. What if I don't fail in that quarter? I don't get my bonus. To which I only had one answer. And remember, this is management consultant heaven. The answer is, you're fired. Why? Because either you're lying to me, or two, you're not taking up risks. Both of which is not part of the culture that we want to develop. Obviously, it didn't tell them they were fired, but that was the principle. So this was a way that we tried to develop, to measure a learning mindset. And once again, and remember, safe to fail is not the totality of a learning mindset, it's just an element of that. The second domain is a collaboration mindset. And this is somewhat similar to structural agility, but it goes to the way in which we work. Somebody, to speak of firing people, this is one of the things that has somebody to say, that is not in my job description. There's not an agile organization. You may not know how to do something, but we're working collaboratively. We are working towards a common, common, common, common. If you have to roll up your sleeves and do something that, hey, let's learn something new, or I'm gonna go and do that job for a week because someone's just called in sick and we have a release next week, then that's what's gotta be done. And this goes cross silo. A collaboration mindset is not where you go, I've done my work, I've handed it over to the dev team, it's with them. I have just abrogated my accountability, or I've tried to anyway. I've said, it's with them, I'm fine, I've done what I needed to do, it's with them. Go talk to them, don't bother me anymore. Collaboration mindset, there's, no, you own, if you touch it, you're part of it, till it's gone, until the end. And this is fundamentally where agile organizations, because you've got this accountability, because you have this authority and the autonomy that comes with that. It comes with, you must collaborate. You don't get a choice, you can't hand off. I'll give you a good example, and this covers a couple of the domains. I was working with a trading organization, sorry, a software organization, also in Singapore. And this organization had a problem with their, the customer satisfaction was low. What was basically happening was that the sales team were selling more than could be delivered, because the sales team was being measured, or being paid on commission, but being measured on the number of sales. And if they sold something that was either impossible to deliver or couldn't be delivered in the time or whatever reason, that wasn't their problem because they handed the problem off to the dev team, who got wrapped on the knuckles when the forecast wasn't met, not the sales person, they've moved on, they've got their commission, they're trying to sell the next thing, but the dev team. So this organization realized they had a problem so they did a couple of different things. The first thing that they did was they got rid of the sales team. Actually, technically, not quite true. They got rid of the team, but not the sellers. The sellers got embedded into the delivery teams. Talking about cross-functional teams, this is about as cross-functional as a guess. Sellers embedded into the delivery teams, they became more account partners than sellers per se that they did have to go and build their business. It improved collaboration, but there was a few things that, that was step one. What was still happening was they were still trying to sell more. They couldn't save it anymore, which meant their job satisfaction went down. The dev team's just action didn't really go up. So we just bought everyone at a really low level, which is not what you want to do. So a little bit further, when you said, why is this? Well, to my point earlier, you get the behavior that you know. So if it was the sales API, they would have changed it. They were no longer paid on the sale. People would pay the salary like everybody else. Bonuses are paid to buy a team. So first of all, team morale went up. Cause the worst thing you can have is one team member being paid half a million dollars for doing something and then you do all the work to build it and you just get a salary. So we bought everyone's salary to a base level and there was a much smaller bonus. The best sellers, their average annual take home money went down, the worst sellers went up a bit but everyone sort of ended up neutral. As a side note, we lost about 30% of the sales team when we did this. But that was actually okay because once we'd normalize the KPIs, once we'd normalize the incentives and the motivations and the pay and all that sort of stuff, once we built it all together, a remarkable thing happened. Team morale went up. They started collaborating quite closely together and repeat business from existing customers went up by 80% and for those of you who don't know, it costs more to acquire a new customer than to sell to an existing customer. So if you can increase repeat business, that is the best thing that you can do in an organization. So with that increase, new sales went up by about two or three because it was statistically insignificant increase in new sales. So that change in how that sales team operated was a fundamental shift in collaboration. It's why we made that change. The final domain, ownership and that should be an ownership mindset not ownership duality. No ownership mindset is one of perfectionism. I take pride in my work, I'll make sure it's done right each and every single time. Perfectionism is not the same as ownership. But this is about making sure that I take pride in what we as a team do, that I as an individual do and that I want to make sure that we are going to serve the customer to the best of the ability within the strengths that we have. If I can take a level of pride, I can't own it. And there's a question that you have to be able to ask. Do you take personal pride and ownership in the financial health of your company? You don't have to answer. Most of you the answer is probably going to be, no, that's my boss's job. That's not business agility. Ownership means I'm going to take pride. Does it mean I'm going to stay in this job the next 30 years? No. Of course I might leave in two years but when I'm there, I'm going to take that ownership of the work that I'm doing. That is agility. So these nine domains, these three dimensions, as I said, this is not a framework. It's not telling you how to do anything. Scrum is process agility, a bit of learning agility, collaboration agility, right? Beyond budgeting, you've got some leadership agility, you've got some technical agility because accountants are agile too. You've got some collaboration, learning and ownership, fantastic. Spotify model, all that structural agility and about it. You want business agility? It's not one thing. It is your organization coming together as a as a single entity and changing all little parts. Remember Evan's theory of agile constraints? Somewhere is your constraining factor, right? And you can use something like this to help you go if it's not process, if it's not IT, where is it in the organization and what can we do to fix it? Thank you. Questions? Big voice. When the organization is new to agile framework, that's where we, what I have observed is that we struggle with the collaboration. Why? Because the top performer is always overloaded and the top performer actually hide behind the seat. Now when the maturity goes up, it's really good because everybody participates in that. That's where the struggle comes that how we actually give a fairness to the good performer over there. So two suggestions with that. First of all, introduced pair programming because you wanna upscale the scale of all of the teams and the programming is not just for good and poor developers. You want people all different sets working together. And what you'll see is that you'll see the staff performers perhaps aren't as good as you think they are. They may be a good developer, but they may be weak in other areas and you'll start to see a consolidation of skills across multiple teams. You also may wanna consider something about self-selection. There are organizations out there that will allow individuals to self-select into teams and projects and products that they're working on. And one of the advantages that you get is first of all, they will get a sense of personal motivation because they have selected what they're gonna work on. And there's entire, and there's books on self-selection to make sure you get the balance right and skills right and all that sort of stuff. But when you do that, what you find is because you've got that personal motivation, you've got mediocre performers who suddenly become much better, much more actively engaged because they're personally brought in and personally motivated by the work that they're doing. It's, and then the other thing is if you really have a bunch of really low quality people, you've got a different problem. All right, so. I understand that. Hopefully that's not the case. Hopefully it's just a matter of skill and experience in which case time, effort, pairing, self-selection will help some of those issues. Thank you. One last question. Another one. I have a round. Hello. I'm quite interested to know that we can have something like failure KPI. Yes. And if you see the current model. This was an Asian company, by the way. The current model is like we always have a KPI that your budget accuracy should be 99.99%. Your defect should be this, this, this. So this is first time I'm hearing. So I mean, do you have a case study or more example that once it is being implemented? So I gave you one example. I've actually implemented failure KPI in four organizations in the past. So in each case, there's been a positive outcome. But I will actually go more fundamentally. You get the failure KPI for a moment. You get the behavior that you measure. I've said this multiple times. If all your measuring is financial performance, you're going to be optimizing purely for financial performance and not for customer needs. The KPI's that you have, or OKR's, KPI's outcome profile to pick a model that you want, needs to be focused on what does the customer want from us. The financial elements are nothing more than a metric. They're an indicator that we are serving our customer. They are not the measure, sorry, they are not the outcome that we're trying to achieve. So there's a more fundamental issue about what you're measuring and why you're measuring it. And another thing around, when you say your KPI's around money, I'm going to guess your organizational scorecard also has a customer satisfaction KPI. Most do, right? Does anyone get fired if the customer satisfaction KPI's not hit? No, do they get fired if the financial KPI's not hit? Maybe, probably, right? So the incentives and the penalties for not meeting certain KPI's are different, which means I don't give a damn whether we hit customer satisfaction because I'm going to get fired if we don't hit the target for this quarter. So that's all I'm going to focus on. And it doesn't matter what other KPI's are put in place, that's the only one that really matters, all right? So the rewards and benefits for the KPI's have to be systemic as an added systems level, not just individual, which is you hit this one, great. You hit the rest, and that's just icing on the cake. Similarly, going back to why you exist, right? This idea of measuring what... I'll give you another example, and I know I'm out of time, so I'll be very, very quick. I used to work for IBM, and I probably shouldn't say this, but I'm going to anyway. We made a change to the account model of how we operated with some of our big clients. Big vendors have accounts, teams of sellers and specialist skills that will go in and try and sell more stuff to that client. So we went into the client, and it's like, the account structure was based on IBM's product offerings, which is fine, but that's not how the customer wants us. The customer has a problem that they need to solve, right? So we shifted it, and we said, okay, customer, what are your organizational scorecards? What's your KPI's? And we gave those KPI's to our sellers, right? So this changed the behavior, and yes, they still had to sell a certain amount per quarter because it's the IBM, but I'm now no longer selling one product. I'm selling a product stream because I'm focused on, you're my client, you're trying to achieve, you're trying to release a new product, a new banking product to market, great. That is my KPI as well, and whatever I can do to help you achieve that is what we're gonna do. My bonus relies on you being successful, right? And that really changed the level of conversation in the organization, right? It stopped being about, hey, we have a new product, please try and sell it. It became a, how can we help them achieve their goal? And sometimes the answer was, you know what? You should go to this other organization because that product is gonna help you rather than try and sell IBM every single time. So I'm now completely out of time. If you have any questions about what we're doing with the Business Digital Institute, come up and chat to me after this. Thanks even.