 Hello everyone and welcome to the don't bulldoze this ramp for Jail session. So we have our speaker today as Steve Adolf and we are glad that they could join us today. So a quick introduction to Steve Adolf here. So they are Jail Poach at Sea Prime and they are joining us today from the West Coast Canada. So they are a leader. So they are an internal leader with an international experience in creating leading edge businesses and technical solutions to rare combinations of development skills. And people focus coupled with business vision and management expertise. So they're highly adept at integrating business goals, technological capabilities and customer needs to produce solutions, satisfy customer and drive business growth. So without further delay, I 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, you know, like ask yourself, who's currently in an organization that's undergoing an agile or digital transformation. This is, you know, 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 banks said to me. This is the fourth time we've been at this rodeo. So what's going on. Well, here, here's the thesis I'll put to you upfront, what one potential root cause for why transformations fail. And I'll say they fail because we introduce a machine consistency. You know, 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 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 social technical 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 greeting principles. So how do the five guidelines or principles for green transformation. So the metaphor I like to use a lot for organizations or is the swap. And swaps 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 there if you're in the American Southwest. There is, you know, midway, you know, Gulf Coast, there are alligators. Right, so these 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 where we can't coordinate deliveries unpredictable. You know we rely on heroics. And so what what ends up happening. Of course, a well intentioned leader says, Okay, enough. You know, I'm tired of her week. 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. We transform, you know, 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 that you know 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 you know us core army engineers did they said well bulldozer, pave it over. So now you've got this beautiful consistent swap. We've got this consistent concrete river here that reduces flooding in Los Angeles. So what you know 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 systems 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 what in the meta and 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 part of the argument is a why a large number of our agile transformations fail. So how does this happen, why, why is this going on. Okay. The metaphor of the bulldozer. The bulldozer here represents a technical transformation so the bulldozer is representing that what our approach to performing an agile transformation is to take a technical process and tools approach. You probably have seen 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 gets centralized. Right, even adding a person to the tool means going through some kind of tools groups now. The practices are more driven and the tooling and the actual practice we adopt are more driven by the reporting needs of the organization, then they are by the actual workflow needs of the teams. And we enforce this all with the tools. So we are for, we're enforcing the practice with the tools and inhibiting the ability of the teams to experiment and improve their practices. This becomes on maturity, right agile maturity, we, 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 a, 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. 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 variants in our system to embrace that change. So the argument is, well, look, we're not like that. We're agile, you know, we're different, you know, individuals and interactions right. Well, that may be what I thought but a green bulldozer is still a bulldozer. And my really my worry is that really this is what's happened to to our interpretation of the agile manifesto. Is it really 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 and if you've done and 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 the what it really is all about. It's really it's really quite as simple. It's a book about different models or different lenses that we can view an organization through. 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, you know, 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. 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, you know, say is the antithesis of agile. 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. You had the fine 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. The models work really well when you've got straightforward tasks, you got a stable bar, think of a manufacturing, think of the turn of the last century, where a lot of workers were illiterate, and we're just trained to do piecework think of Henry Ford assembly lines. Now does that sound like software development. And more important. So in this machine model. Is that really gating and 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. That 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. Rather than a processes and procedures view of the organization that came with the machine model and stressing consistency. We asked 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 the that becomes our interest. And you can think of how a biological system works like take this or apple orchard for example. Right. The, you know, I exhale carbon dioxide, this tree takes in carbon dioxide. So we have any resource exchange and it admits oxygen. It grows, you know, it takes in nutrients from the soil and water. It grows this apple. I eat the apple. I contribute back to, you know, 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 who 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 take, do we adopt a machine model where consistency means conformity, and we have the same tools and practices. Or do we take a by a lot. Can we take a biological view of consistency and look at it from the point of view. Can I efficiently change exchange resources with the other units in our organization. Can I sufficiently coordinate with them can I sufficiently exchange 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. There's really quite fascinating story here of what the Heimler coal mines. And this is part of an argument that I always say that, you know 1940s coal miners knew more about agile than software engineers in 2022. So, winding the clock back to the 1940s. They needed a lot of coal to support the war but also just after the after their war to support the growth of their industry. And new technology was being introduced in a lot of the minds replacing what was called the long wall method with a new method called the short wall advanced pillaring in, you know, roof support systems that allowed the, that 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 Heimler, 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 that 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 chap here turns went to investigate the, the minds, and it was interesting to research and he came out with in the end he said, you know the dramatic improvement in productivity at the Heimler coal mines is an example of a socio technical system. The modernization'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 procedure standard practices in place. So, we're going to find optimization of the technical and social aspects. Remember, the worker, the new technology was introduced, the workers then reorganize themselves socially. Thus, exploiting the adaptability and innovativeness of people, they could embrace change. So, if we look at it through this socio technical lens, we start to see, how can this work for us. The idea that we were able 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 call 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, and able to their ability to innovate, not suppress it. So, if you model this what we can see in this idea of a socio technical system. We have a technical system. This is concerned with our processes and tasks are ways of, you know, our tooling. Our technology support. Our social system is the people, the nature of the people the attitudes our relationships, the authority structures you know power gradients. And when we're improving a system, when we're adopted going through an agile transformation we just cannot. The machine model the bulldozer it effectively is going. It effectively it effectively is destroying that part of system. So we need to preserve 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. We need we need guidelines for how do we preserve that ecosystem. How do we preserve the social system when going through an agile transformation. You know you might you might take this back a bit and say well, wait a minute. People are valuable to us, you know, our executive our CTO says always help people are really valuable. There 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 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. You know, for do you force all teams to use the same workflow. Here's, here's one that is always a bit a big red flag for me. How do you treat the scrum masters in your organization. So many of the organizations I work with. The scrum masters are almost a commodity, you know, or are they really valuable. What's the ratio contractors. And what's the turnover like in your organization. So these are really good, you know, deep questions to say like, do we value that social system. So how do we transform, you know, we say okay let's put an emphasis on the, you know, let's sort of deprecate this machine model but how do we avoid this, 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. Remember, we've got sort of like, you know, five principles for guiding, you know, for guiding an agile transformation that helps preserve that social system enables us to take a social technical approach. The first principle is principles zero. Know why we want to be agile. Okay, this is always a big problem in a lot of organizations you say well why do we want to be agile and, 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. Right, you are adopting agile because you want believe you will get economic gain through fast learning cycles. That is why, you know, cost reduction, increase output, those are side effects, but the justification for agile is, yes, we strongly believe that if 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. The economies of scale reduced 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, in a season, they came out with 30. They were able to learn very quickly what people really wanted motorcycles. Within one year, Yamaha could not sell their inventory. That is the power of agile economics principle number one. Remember that I think about the social technical systems we are able to set the objectives but people, 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 a great video if you want is this by David Marquette. He tells the story of how he was a former US Naval submarine commander. 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 become a big part of reading the transformations in a 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 bulldozers 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 want we go through compliance and we want people to comply with the methodology. We are actually declaring a work to rule campaign on ourselves. We've ever been part of a union. I was a long time ago a shop steward in it 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 want, and we didn't want to go on strike. We would follow the contract. We would do precisely what we were told to do. We call a work to rule campaign, where you do you comply with the way of working exactly. And then 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 look, this is a line that I love from calling. I want to unleash my team. I don't want to control them. I want 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? What is it, you know, if we take an automobile dashboard, right? We could, you know, we could look at this as typical of what we measure in most of our programs and in our teams, right? You know, you look here, here's on the automobile dashboard, there's the oil pressure, there's the amps being generated, there's the water temperature, right? This is measuring the health of the car here, right? 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, right? 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, it's on a dynamometer. It ain't going anywhere. But, you know, it's probably, it's water temperature, oil pressure 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. You know, we all hear it, oh, 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 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, health 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, again, thinking about agile. Economic advantage through fast learning cycles. This I call the Vegas principle. And this is kind of what the principle that more or less makes 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 know, you see the movies and we all know the stories. But there's 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. So what you if we have several different teams in our 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 for 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, they'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 con but 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 masters participating in the art in the art sink. But how you do your work, how you decide to do the teams work. That's up to you that name that creates that 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 you have to be able to encourage it. You have to be, 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 put they created that time through for relentless experimentation and learning. Wonderful little example of this a story in sometimes called the pursuit of flight. So most of us know probably think yep, the right brothers were the were the first to fly they were. A couple of bicycle repair mechanics think about this for a second, a couple of bicycle repair mechanics who relentlessly experimented with models and wind tunnels gliders for 12 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. And so the US government said, fund me, and I will build, I will be able to build an aircraft that will fly heavier than air aircraft that will fly. And so he designed it, built it, put it on to 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 in the houseboat launched it, it crashed into the water again. And this was always used as an example of this power of rapid experimentation. This was following a plan this has that lovely certainty of were 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 scientists with government funding, and not all experiments are going to go well. Well, 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 and 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 re greening of the Los Angeles River. This is actually the law. This is actually this as it's being re green to now in Los Angeles. You know, to really wrap this up, there's 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 we can the cons of the adopt if we were adopting agile. It means we believe that growth that learning is gives us economic advantage conformity jail set is the enemy of that growth. So to summarize what we've done here is 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 do socio technical theory, talking about when we going through a transformation we must give equal assertion and care, and focus and hold 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. Great. It was it was really an insightful session Steve. Thank you. Cool. So we have one question up till now so everybody anybody who has any more questions I think you know you can put it in the Q&A section and we'll start with the first question mean why. This is from Savika Lam, I hope I pronounced it right. So they asked how do we marry outcomes with output. Well I think the first. It's really good question. What do you what the first thing is being clear on what your outcome is what what, and that goes back to that can we have expressing 10. What is the outcome we are we are seeking. And a lot, you know, one of the one of the ways a lot of organizing, you know 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 okay ours and objectives and key results. The outcome what we want to be able to do is relate the outcomes clear relate the outcomes to the outputs. And when we're looking at our outputs, if we're increasing velocity, is that having any actual effect. It's a relation that relationship isn't having any effect on a desired outcome, we're getting more output. Are we getting a better outcome where, you know, though that's, we're getting shorter cycle times, are we getting better outcomes. So that's the way that we need to be able to need to be able to look at we have to be able to look at when we're improving our outputs. Is it changing our is it changing is it changing our outcomes. Sometimes what I like to do is when especially when we're working with a with a team is set is really looking at it. We're 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 this is the that's that relentless experimentation we were talking about. Cool. I hope that answers your question, Sabika. You may have if you have any follow up questions you can you know feel free to put them. So there's another one related questions team so this is by Tom Gilb. So he asks, among outcomes to you include critical qualities like security usability adaptability and other stakeholder values. Always it's always understand I 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. How what 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, you know, mission critical systems, you know, the security the usability the adaptability, the stakeholder values. These are important these form important parts of that outcome. Okay, great. I hope that answers your question Tom Gilb. 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 they further ask any tools that you would recommend to measure outcome. There's a there's a number number of them right now what a lot of people are excited about or trying to work with is that definitely working with okay ours. So the objective and key results. What are the challenges I have is of course like any wonderful idea and I'm a big fan of okay ours is in many organizations they deteriorate into management by objectives. So that's always a big caution you have to have, but okay ours are, you know, one effective way to say what are the important outcomes that we do want to achieve here. Now there's a number of there's enough, 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. And put it this way sometimes the tools take you into a management by objectives mode rather than really thinking about an okay what an OPR is really all about. Thanks. So I think you know there's a there's another question from Alia Dixit. They have to ask based on your 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. Deaf, you know, I would say though from, you know 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 you need it's, and I mean management leadership not management going, hey you're doing that actual thing. Oh that's so cool. Let me know how that works. You know 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 for approach where the management 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 space you know we're going to create the time and space for you to innovate. So there is you know I you know I think in that description it comes more along the lines of you know the sandwich approach yes we have the top down. We are setting the intention, we are giving the guidelines, there is going to be an definitely an element of our frame framework in there. But here is where you as a team can innovate. So, you know, there's definitely, I think we're arguing for both the top down and bottom up and I'm assuming that's what Aliya 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 the between. Yeah, but it is really you know it's management sets the intent right that's what leadership needs to do that go back to Captain Marquette there to turn the ship around. He was able to take a change the culture on a submarine by changing the way he's the language he used and communicating with this crew. He set the intent, the crew responded. That's very much the model we're looking for here. There are practices of procedures that you know they people were you know 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 the questions because she has responded with saying thanks to you. So, yeah, I mean I had a question from my end as well but I think you know to some extent you. I think answered. So how I mean I was about to ask how do we foster agile mindset or you know use the failures which have come across and convert them into opportunities through the you know agile mindset. We want the team to adopt. It's one of the things about fostering the agile mindset is to really understand what agility is all about. And, you know I keep I keep coming back to it we've got to. It's not only just as engineers and software developers that we have to, we have to help our, we have to help our leadership understand what the economic advantage of this, because that's if they're going to lead or if leaders are truly going to lead an actual transformation in the organization. They've got it they need they seriously need to be able to see it from that economic what is the economic advantage we're getting. Okay, okay. Right, right. I think we are two minutes or what about any, you know, I think this this was really a great session. Steve, thank you, thank you so much for that. It's been my pleasure.