Video details

Don't Bulldoze The Swamp For Agile by Steve Adolph

Agile
10.12.2022
English

Large-scale agile transformations do not have a good track record with reportedly up to 70% falling far short of their goals.  From a biological perspective,  many agile transformations are like taking a bulldozer to a wild, diverse eco-system.  While we may create a consistent Way of Working, the transformation bulldozer often results in a monoculture,  a weakened ecosystem that cannot adapt and innovate. Of course, to work together, especially at scale, we cannot just let our enterprise eco-system grow wild because we need consistency to collaborate and coordinate. We can resolve this dilemma by taking a page from Socio-Technical systems for a more sustainable transformation.  We introduce five principles for the "Greening" of the Agile Transformation that sustains and grows our capability to innovate while creating needed alignment and consistency.
More details: https://confengine.com/conferences/agile-india-2022/proposal/17042
Conference Link: https://2022.agileindia.org

Transcript

Hello, everyone, and welcome to the Don't Bulldoze, the slam fragile session. So we have a speaker today as Steve Adolf, and we are glad that they could join us today. So a quick introduction to Steve Adolf here. They are a giant coach at Sea Prime, and they're joining us today from the West Coast, Canada. So they are a leader. They are a leader with an international experience in creating leading edge businesses and technical solutions to their combinations of development skills and people focus. Coupled with business vision and management expertise, they are highly adequate at integrating business goals, technological capabilities, and customer needs to produce solutions, satisfy customer, and drive business growth. So without further delay, over to you, Steve. Good evening, everyone. And for me, good morning. So, got a bit of a metaphoric title to this presentation, don't Bulldoze the Swamp for Agile. So the first question I would really sort of ask yourself, who's currently in an organization that's undergoing an agile or digital transformation? Quite a few organizations are starting to take this on. And if you are on this road to the Emerald City here of the Agile Digital Company, you better strap in. It's going to be about a bumpy ride. Now, depending on whose numbers you pull, about 70% of these transformations fail. I know from my own experience, one of the clients that I've had at a major US. Bank said to me, this is the fourth time we've been at this rodeo. So what's going on? Well, here's the thesis I'll put to you up front. One potential root cause for why transformations fail. And I'll say they fail because we introduce a machine consistency. We start imposing standard practices and tools, and the result is the creation of an unhealthy ecosystem. And the unfortunate aspect of that unhealthy ecosystem is it diminishes the ability of the organization to innovate and adapt. In other words, it diminishes the ability of the organization to embrace change. So the outline I have is I'm going to introduce a biological model to explain why agile transformations can fall short of their ambitions as a way of maybe greeting the transformation up, if you like. We'll take a quick look at sociotechnical systems as an ability, as a theory that we could use to restore balance in that ecosystem. And then I'll introduce five guidelines that sort of try to use when we're working with an organization that really helps implement those breeding principles. So how do the five guidelines are principles for green transformation? So the metaphor I like to use a lot for organizations is the swamp. And swamps are some of the world's healthiest and most productive ecosystems, but they're also dangerous. Any swamp around the world, there are parasites, there are snakes. If you're in the American Southwest, there's Midwest, Gulf Coast. There are alligators, right? So a swamp is this productive ecosystem. It also is dangerous. And it becomes a lovely metaphor for trying to describe a software development organization or product development organization. Right. The software swamp is potentially productive. We've got great people who want to accomplish great things. It's also a dangerous place. Why? Because we may have islands of agility, ad hoc methodologies. We can't coordinate deliveries unpredictable. We rely on heroics. And so what ends up happening is, of course, a well intentioned leader says, okay, enough. I'm tired of the coordination delays. We need everyone to be on the same page. We need a consistent process. So what do we do? How do we fix that swamp? Well, we send in the bulldozers. Alright? We transform. We transform nature to suit our need for consistency. We bring in the consultants, we bring in the training, we bring in the frameworks. And what's the result? Well, we get a well structured, consistent system. I don't know how many of you might seen this if you visited Los Angeles or you may have seen this in a lot of Hollywood movies. This is the Los Angeles River. And it literally was a swamp at the turn of the last century. And it caused a lot of problems in Los Angeles. It regularly flooded. And so what? The US. Corps, army engineers did, they said, well, bulldoze, it pave it over. So now you've got this beautiful, consistent, beautiful, consistent concrete river here that reduces flooding in Los Angeles. That's why I'm using a gate as a metaphor. So we've got now this consistent system. Everybody uses the same framework in a software perspective. We're all using the same terminology. We've got the same tools, we've got the same workflows, we have well defined rules and we have a dead ecosystem. No one would ever say that the La River, after it was transformed, after it was bulldozed, is a lively, prosperous and productive ecosystem. And that's where we start getting in, extending this metaphor. What we've done is we've killed the ability of that system to adapt, innovate and grow. We have basically the system can no longer embrace change. And this is part of the argument to say why a large number of our agile transformations fail. So how does this happen? Why is this going on? Okay, the metaphor of the bulldozer, the bulldozer here represents a technical transformation. So the bulldozer is representing that our approach to performing an agile transformation is to take a technical process and tools approach, and you may have even seen these, where we adopt a tool and a framework top down in position of the tools and the framework decision making get centralized, right? Even adding a person to the tool means going through some kind of tools group. Now, practices are more driven and the tooling and the agile practice we adopt are more driven by the reporting needs of the organization than they are by the actual workflow needs of the teams. And we enforce this all with the tools. So we're forcing the practice with the tools and inhibiting the ability of the teams to experiment and improve their practices and our emphasis becomes on maturity. Right? Agile maturity. And that really is meaning are we compliant with the practices we've adopted? We're not focused on the outcomes, are we actually getting anything better out of this? And so by taking this technical approach to the agile transformation we are suppressing the best part of agile because why are we adopting agile? Agile is we have to understand that Agile is much more than the Manifesto. Agile is a strategy for economic gain through fast learning cycles. That is why we're adopting agile. We're saying that we want to be agile because we believe for our organization we will get economic gain through fast learning cycles. That's what embrace change means. That goes right back to Kent book. Kent next book, Embrace Change. We get economic advantage to these fast learning cycles. When we introduce the bulldozer it crushes out that ability, that inhibits that ability to experiment, to have variance in our system, to embrace that change. So the organism, well look, we're not like that. We're agile, we're different individuals and interactions. Right? Well that may be what I thought, but a green bulldozer is still a bulldozer. And my worry is that really this is what's happened to our interpretation of the Agile Manifesto is have we really replaced individuals and interactions over processes and tools with processes and tools over individuals and interactions when it comes to executing an agile transformation? So to sort of clarify this and to look at a different approach, I'd like to introduce this book here. If you've been in an MBA program or organizational behavior you may have seen it before. This is Gareth Morgan's Images of Organization and what it really is all about. It's really quite a simple it's a book about different models or different lenses that we can view an organization through. For example, we can think of an organization as a machine, we can think of an organization as a biological system, we can think of an organization as a neurological system or a cybernetic system. So these are all different views of the organization and we'll look at two of them here. The first one is the classic the organization as a machine and probably been the agile world. You've heard of this person here, Frederick Taylor, who we all love to go say is the antithesis of agile, right? Frederick Taylor is the chap who came up with the principles of scientific management and he very much looked at the organization as a machine and strove to get economic gain by adopting machine efficiency. So the emphasis here was on the efficient delivery of output. So you had a bureaucratic organization, you had management designing the ways of working, you had workers executing the ways of working. So you had well defined job descriptions, management by objectives, all the responsibility for planning and the way of working laid with management. Consistency here meant we were all using the same tools and practices. We were getting efficient execution of the machine model. But the question I have is that a model that's appropriate for software development, right? Mechanistic models work really well. When you've got straightforward tasks, you've got a stable of art. Think of a manufacturing, think of the turn of the last century where a lot of workers were illiterate and were just trained to do piece work. Think of Henry Ford's assembly lines. Now does that sound like software development? And more important, taking this machine model, is that really gaining an economic advantage by embracing change? If we are trying to have consistent, straightforward tasks, no variation, that does not sound like we are embracing change. So let's take a different view of the organization. What if we looked at the organization as a biological system and biological systems are open systems that must adapt and grow to survive, right? They embrace change, right? Think of this. Let's go back to our swamp here. It's a biological system. And in this model here we look at the organization as different subsystems or different units within the organization as being able to exchange resources. So rather than the processes and procedures view of the organization that came with the machine model and stressing consistency, we ask the question can the, can the systems within our organization exchange resources? Can we exchange information? Can we exchange funding? Can we exchange software? Can we exchange product? That becomes our interest. You can think of how a biological system works. Like take this apple orchard, for example, right? I exhale carbon dioxide. This tree takes in carbon dioxide. So we have a resource exchange and it emits oxygen. It takes in nutrients from the soil and water. It grows as apple. I eat the apple. I contribute back to be delicate. I contribute back to the soil, to the nutrients in the soil. So there's this ongoing circular exchange of resources that's taking place and this becomes a very different model in which to look at the organization through. So where we want to take this is to say yes, going back to our manager says we need to all get on the same page. Yes we do. But what does it mean to be on the same page? Do we adopt a machine model where consistency means conformity and we have the same tools and practices? Or can we take a biological view of consistency and look at it from the point of view? Can I efficiently exchange resources with the other units in our organization? Can I efficiently coordinate with them? Can I sufficiently exchange information? And that becomes a very different view of consistency and being on the same page. So now the question is how do we do that? How do we take that biological model and make it operational in our organization? And that brings us to this really quite fascinating story here of what the heim were coal mines. And this is part of an argument that I always say that coal miners knew more about agile than software engineers in 2022. So winding the clock back to the 1940s, england needed a lot of coal to support the war, but also to support, after the war, to support the growth of their industry. And new technology was being introduced in a lot of the mines, replacing what was called the long wall method with a new method called the short wall advanced pillaring in Roof support systems that allowed the allowed a change in the way that the workers were operating. So we had a new technology introduced into the mines. What happened was that one of the mines, the hymor after the introduction of the new technology, the productivity skyrocketed almost by an order of magnitude. Well, of course, all the mine managers were like what is going on here? We've got to go and copy these practices and introduce them to the other minds. And what it turned out had happened is the introduction to the new technology. The workers took advantage that they could change their working practices to leverage the technology and they organized themselves into small cross functional teams where they met daily to decide what their outcome for the day would be and how they would achieve it. Sound familiar? So this, this chapter turns went to investigate the minds and it was interesting the research that he came out with in the end, he said, you know, the dramatic improvement in productivity at the Heimark coal mines is an example of a socio technical system where an organization's objectives are best met not by the optimization of the technical system. Right? That's the machine model and the adaptation of the social system to it. In other words, we're going to make you all comply with the machine, we're going to put standard operating procedures, standard practices in place, but the joint optimization of the technical and social aspects. Remember, the new technology was introduced. The workers then reorganized themselves socially, thus exploiting the adaptability and innovativeness of people they could embrace change. So in other words, if we look at it through this sociotechnical lens, we start to see how can this work for us? The idea that innovation and embracing change comes from people, not this machine. So they were able to exploit the adaptability and innovativeness of people in achieving goals instead of over determining the manner in which these goals were achieved. So the teams themselves could decide how they were going to execute their work. They understood what needed to be accomplished. They then decided this is what we need to this is how we will accomplish that. They weren't constrained by this machine model the technology, in other words, the technical system. Their tools enabled their ability to innovate, not suppress it. So if you model this, what we can see in this idea of a societychnical system, we have a technical system, this is concerned with our processes and tasks, our ways of our tooling, our technology support. Our social system is the people. The nature of the people, the attitudes, our relationships, the authority structures, your power gradients. And when we're improving a system, when we're going through an agile transformation we just cannot the machine model, the bulldozer it effectively is effectively is destroying that part of the system. So we need to people are the innovators when we take it. When we bring in that bulldozer we're crushing that social system. That's where we get the dead ecosystem. So we need guidelines for how do we preserve that ecosystem, how do we preserve the social system? When going through an agile transformation you might take this back a bit and say well wait a minute. People are valuable to us. Our executive, our CTO says always how people are really valuable. These are all issues I've seen in many of the transformations I've been part of. Who decides on the way of working? Is it the team or is it some centralized organization? Who pushes a machine model down on the teams? Is the model or the way that the teams are working? Is it driven by the needs of the team to get their work done or is it driven by the reporting needs of the organization? Do you force all teams to use the same workflow? Here's one that is always a big red flag for me. How do you treat the scrum masters in your organization? So many of the organizations that I work with, the scrum masters are almost a commodity or are they really valuable? What's the ratio of contractors and what's a turnover like in your organization? So these are really deep questions to say like do we value that social system? So how do we transform? We say okay, let's put an emphasis on that. Let's sort of deprecate this machine model. But how do we avoid chaos if we just let everyone decide how they're going to do things? That takes us right back to the swamp. So we've got a number. We've got sort of like five principles for guiding for guiding an agile transformation that helps preserve that social system and enables us to take a socioechnical approach. The first principle is principle zero. Know why we want to be agile? This is always a big problem in a lot of organizations. You say well why do we want to be agile? And there might even be some hesitancy right. If you're saying well, we want to reduce costs, we want to increase our output wrong answer. There is only one reason you're going to adopt agile. You are adopting agile because you want believe you will get economic gain through fast learning cycles. That is why cost reduction, increased output, those are side effects. But the justification for agile is yes. We strongly believe that we go through fast learning cycles and we embrace change. We will get economic advantage a classic case study of that is the so called Honda Yamaha Wars. Yamaha started the war by building a massive factory to build motorcycles, right? Economies of scale reduce the cost of the motorcycles. That's the machine model. How did Honda respond? They accelerated their design cycle. So instead of coming out with 15 motorcycles in a season, they came out with 30. They were able to learn very quickly what people really wanted in motorcycles. Within one year, Yamaha could not sell their inventory. That is the power of agile economics. Principle number one. Remember that thing about the social technical systems? We are able to set the objectives, but people get to say how they will achieve those objectives. So, most important, set the objectives. Make sure you're giving clear, consistent communication. You're setting intent. A really great book and or great video if you want, is this by David Marquette. And he tells a story of how he was a former US Naval submarine commander. And he tells a great story of how he took the crew of the worst performing submarine in the US navy to be one of the best by changing his command style. As he says, I vowed never to give another order, rather I gave intent. He actually began letting the crew decide how they would get their jobs done. And this is really, this has becomes a big part of greening the transformation and truly giving people the authority to make the decisions about how they get their job done. But to do that, they need clear intent. And this comes back to what the bulldozer is really all about. The bulldozer, the machine model is all about control. Remember that Frederick Taylor thing? Management decides on the way of working workers execute and the more that we strive, hey, we go through compliance and we want people to comply with the methodology. We are actually declaring a work to rule campaign on ourselves. If you've ever been part of a union I was a long time ago. A shop steward in a union. We used to have something called a work to rule campaign. A work to rule campaign was when we got annoyed with our employer and we didn't want to go on strike. We would follow the contract, we would do precisely what we were told to do. That is actually called a work to rule campaign where you comply with a way of working. Exactly. And in a lot of jurisdictions in my home jurisdiction now, or British Columbia, that's actually considered to be an illegal strike, right? Control is illusory. And this is a line that I love from colleague. I want to unleash my team. I don't want to control them. We've got people who want to do amazing things. If you give them the intent, they know what needs to accomplish, they will get it done. Next principle. You've probably all heard this right. You can't manage what you can't measure, right? So what do we measure if we take an automobile dashboard, right? We could look at this. This is typical of what we measure in most of our programs in our teams. You look here on the automobile dashboard, there's the oil pressure, there's the apps being generated, there's the water temperature. This is measuring the health of the car here. So these are health or maturity metrics. That's what maturity metrics measure. The health of the team more accurately, the compliance with the practices. Then we have the performance measures, right? Our velocity, how fast are we going, our cycle times, what's missing from this well, are we actually going anywhere that we care about? Are we getting any valuable outcome? And again, this car here, right, isn't on a dynamometer. It ain't going anywhere. But it's probably water temperature, oil pressure, it was all good and healthy. The speedometers right now showing a very high velocity, but it ain't going anywhere. And one of the challenges with agile is everyone often gets obsessed with velocity. We all hear it all. We want twice the work in half the time. Great. Creating twice the garbage in half the time is not really useful. That goes back to this idea, do we know what outcomes we're striving for? What is the real economic outcome? And again, taking and remembering what is agile about getting economic advantage by fast learning cycles? Think of Honda and Yamaha again. Right. Some examples of potential outcome metrics that really depends on what domain you're working in. But if you're working, for example, in web based systems and customer visits to a site, maybe these are some metrics you might be looking at. Do the practices, are the things that we're doing make any difference to the actual outcomes that are important to our organization? Yes. Or maturity metrics are important? Yes, performance metrics are important. But if we're not measuring the outcomes or we don't know what our outcomes are, what does it matter? And also the game we're thinking about agile, economic event, economic advantage through fast learning cycles. This I call the Vegas principle. And this is kind of what the principle that more or less make this system work. This is really taking from a point of view of the biological system. Now, I'm not a big fan of Vegas, but you see the movies and we all know the stories, but the line about Vegas is what happens in Vegas stays in Vegas. And I sort of paraphrase that to say, what happens in your team stays in your team. In other words, it's the rule for the saying that in this biological model which happens inside these systems, stays inside those systems so long as those systems can exchange information and resources. We have several different teams in the organization. I don't care how those teams work inside, I don't care what their way of working is. What's important to me is can those teams coordinate and can they exchange information that's meaningful to them. If they can satisfy that constraint, what I call the Vegas principle, then we have coordinated autonomy. Then the teams are able to decide on their way of working that is optimal for them. So this is the rule. What happens in your team stays in your team. Now, an example for this is I often work with using the scaled agile framework, and you have an agile release train. And an agile release train consists of agile teams. And each agile team on an agile release train will have a Scrum Master. You'll have a product owner, and of course the team. And what I do with the teams, say as a team, I don't care how you do your work, I don't care if you're using Scrum, I don't care if you are using Kanban, I don't care if you're making something ad hoc up yourself. But on the outside you look like a safe agile team. You have a product owner, you have a Scrum Master. You are operating on the cadence with all the other teams. Your Scrum Master is participating in the artsync. But how you do your work, how you decide to do the team's work, that's up to you. That creates the opportunity for innovation, that creates the opportunity for other teams to learn from each of the other teams. Finally, the last principle grow the ecosystem through relentless experimentation. Learning does not happen on its own. You have to make the time and space for it. You have to be able to encourage it. You have to take the mindset that we will experiment. Think again of the Honda. Yamaha wars. Honda quickly experimented with different technologies and different motorcycle designs. They created that time through for relentless experimentation and learning. Wonderful little example of this, a story and sometimes called the pursuit of flight. So most of us know, probably think, yep, the Wright brothers were the first to fly. They were. You had a couple of bicycle repair mechanics think about this for a second, a couple of bicycle repair mechanics who relentlessly experimented with models in wind tunnels, gliders, for twelve years until they were able to achieve powered flight. Well, at the same time there was Langley, who was a respected scientist and engineer, director of the Smithsonian in Washington, and well connected politically, who went to the US government and said, fund me, and I will be able to build an aircraft that will fly heavier than aircraft that will fly. And so he designed it, built it, put it onto this houseboat, launched it, it crashed into the water, he did it again. He literally fished the airplane out of the water, put it back on the houseboat, launched it, it crashed into the water again. And this is always used as an example of the power of rapid experimentation. This was following a plan. This has that lovely certainty of we're executing the plan. The fast learning cycles, the fast feedback enabled a couple of bicycle mechanics to develop flight faster than a respected engineer and scientist with government funding. And not all experiments are going to go well, right? I don't know how many of you remember Elon Musk's joke about rapid unscheduled disassembly of their Falcon boosters, but they went through a large number of experiments. They learned rapidly to achieve this, which I thought was one of the most amazing things that I saw, the landing of multiple boosters after the first launch of Falcon Heavy. So not all experiments are going to go well. So this is where we are. This is our Agile transformation policy choice. Do we want dead conformity or healthy consistency? By the way, this other side here, this is the regreening of the Los Angeles River. This is actually this as it's being regreened now in Los Angeles. To really wrap this up, there is a quote I'd like to bring from John Kennedy. Conformity is the jailer of freedom and the enemy of growth. We need to be if we were adopting agile, it means we believe that growth, that learning, gives us economic advantage. Conformity, jails, that is the enemy of that growth. So to summarize, what we've done here has presented biological theory of why transformations can fail, right? A lot of transformations are like taking a bulldozer to a vibrant and diverse ecosystem and ends up destroying the ability of that ecosystem to embrace change. We introduce sociotechnical theory talking about when we go into a transformation, we must give equal assertion and care and take a holistic approach to growing and transforming both the social system and the technical system. And we introduced the five principles of the Green transformation. Any questions? Cool. Great. It was really an insightful session, Steve. Thank you. Cool. So we have one question up till now. So everybody who has any more questions, I think you can put it in the Q and A section and we'll start with the first question. Meanwhile, so this is from Sabika Lamba. I hope I pronounced it right. So they ask how do we marry outcomes with output? Well, I think it's a really good question. What the first thing is being clear on what your outcome is? And that goes back to that. Can we express intent? What is the outcome we are seeking? And one of the ways a lot of organizations I showed you the Google Heart metrics or the Pirate metrics, one way that a lot of organizations are trying to capture that is the use of OKRs objectives and key results. What we want to be able to do is relate the outcomes to the outputs. When we're looking at our outputs, if we're increasing velocity, is that having any actual effect? It's the relationship. That relationship. Is it having any effect on a desired outcome? We're getting more output, are we getting a better outcome? Where we're getting shorter cycle times? Are we getting better outcomes? That's. Always the way that we need to be able to look at, we have to be able to look at when we're improving our outputs, is it changing, is it changing our outcomes? Sometimes what I like to do is, especially when we're working with a team, is really looking at trying to make an improvement, is treated as a hypothesis. If we get this improvement in our outputs, it will result in this improvement in our outcomes and we'll be able to measure it in this manner. So that's that relentless experimentation we were talking about. I hope that answers your question, Sabika. If you have any follow up questions, you can feel free to put them. So there's another one related question, Steve. This is by Tom Gilp. So he asks, among outcomes, do you include critical qualities like security, usability, adaptability and other stakeholder values? It's always understand. Personally, I would say yes. These are things I would take into consideration. Again, outcomes is really almost with an organization, it's almost an existential issue. Why do we exist? What is it that we do as an organization that creates value? Clearly in an organization, part of the quality of a product that we put out there, especially if we're building mission critical systems, the security, the usability, the adaptability, the stakeholder values, these four important parts of that outcome. Okay, great. I hope that answers your question, Tom. So there's a follow up question which Sabika asked for to her previous question, which was how do we marry outcomes with outputs? So before there are any tools that you would recommend to measure outcome. There'S a number of them right now, what a lot of people are excited about or trying to work with is definitely working with OKRs. So the objective and key results one of the challenges I have is, of course, like any wonderful idea, and I'm a big fan of OKRs is in many organizations they deteriorate into management by objectives. So that's always a big caution you have to have. But OKRs are one effective way to say what are the important outcomes that we do want to achieve here? There's a large number of vendors who do have tools in the marketplace. If you want to capture those formally. Sometimes I find it just more effective to have almost the equivalent of a notebook and write these things down. Because sometimes, I hate to put it this way, sometimes the tools take you into a management by objectives mode rather than really thinking about what an OPR is really all about. Cool, thanks. So I think there's another question from Aliya Dixit. They have to ask based on, based on your experience, what would be the appropriate agile transformation approach? Top down or bottom up or sandwich approach? This is always one of those unsatisfying consultants answer well, it depends. I would say though, from the options given, there the top down, bottom up there's definitely you need a grassroots but you also need management leadership in this. And I mean management leadership, not management going, yeah, you're doing that agile thing. That's so cool. Let me know how that works. A team can transfer, you know, at the grassroots, a team can try something different, but it really is leadership leading and by example. So you need that top down approach where the management is saying, yes, we are doing this. But also, as you see, like through the five principles, management is saying, this is why we're doing it. Because we believe agile will give us economic advantage. We're going to set clear intent and we're going to create the time and we're going to create the time and space for you to innovate. So I think in that description, it comes more along the lines of the Sandwich approach. Yes, we have the top down, we are setting the intention, we are giving the guidelines. There is going to be definitely an element of a framework in there. But here is where you as a team can innovate. I think we're arguing for both the top down and bottom up. And I'm assuming that's what Alia means by a Sandwich approach. Yeah, I think, you know, Sandwich is somewhere between top down and bottom up, I believe, where they meet in between. Yeah. But it is really it's management sets the intent, right? That's what leadership needs to do. Go back to Captain Marquette there to turn the ship around. He was able to change the culture on a submarine by changing the way the language he used and communicating with his crew. He set the intent, the crew responded. That's very much the model we're looking for here. They still have their practices and procedures. People didn't suddenly invent new procedures for operating a subject reactor, but they changed the way that they work together. Cool. I believe that answers her questions because she has responded with saying, thanks to you. I had a question from my end as well, but I think to some extent you answered. I was about to ask how do we foster agile mindset or use the failures which have come across and to convert them into opportunities through the mindset we want the team to adopt? I think one of the things about fostering the agile mindset is to really understand what agility is all about. And I keep coming back to it. It's not only just as engineers and software developers that we have to help our leadership understand what the economic advantage of this. Because if they're going to lead, if leaders are truly going to lead a natural transformation in the organization, they seriously need to be able to see it from that economic what is the economic advantage we're getting? Okay, right, I think we have two minutes. I think this was really a great session, Steve. Thank you. Thank you so much for that. Thank you so much. It's been my pleasure. You.