 Okay, let's get started. I'm allowed to start now. It's after our initial wrong start, but that's okay. So my name is Scott Ambler. I'm here to work through how teams, how you as Agilis can choose your wow. How do you choose your way of working and do so in an effective manner? So I've been, one of the things I get to do, I get to go to organizations around the world help them understand this Agil and Lean stuff and improve the way that they work and improve their organization and improve their working environments. And I luckily got involved with Agil right from the very beginning. And I was the thought leader of the person who led the development of the Agil modeling method which at the time was answering some very serious questions. How do we go about modeling and documentation in an Agil manner? And many of these concepts have been adopted and reinvented in some cases over the years now as well as the Agil data method which is finally taking off. I'm seeing more and more Agil data warehousing teams and the data management folks are finally sort of getting into this stuff. And probably more pertinent is, along with Mark Lyons is in the back there, the co-creator of the Disponential Toolkit and which is what we're gonna be talking about the application of today. So what I wanna talk about, I wanna talk about three steps or three steps to choosing your way of working. First, to understand the situation that you're in and accept that. This is a major step in many cases. There's a lot of people in denial about the actual complexity of the situation that they face. The next step is how do we adopt what we call a guided continuous improvement strategy or a guided kaizen loop depending on the way you like to call that. And then finally, how do we go about choosing and evolving our wow. So let's get into it. So how do we remove our heads from the sand? How do we actually accept our situation? So one of the things we've noticed which I think is pretty harmful is many organizations will call themselves I'm a scrum shop, I'm a safe shop, we're a safe shop, we're a can band shop, we're a less shop or whatever. I hope that nobody, and unfortunately people do, but we really hope that nobody's calling themselves a dispensable shop because it's really, it limits you. When you call yourself an XYZ shop, whatever it happens to be, it limits you to that sort of environment and you really want to pick and choose the strategies that make sense for you. So although if you had to call yourself one type of shop, I guess, dispensable shop is your best bet. Anyways, one of the principles in Dispens Agile is that context counts. And this is one of my favorite diagrams to show to executives in organizations because what happens is when I walk into this diagram and the basic message is that you face multiple, when you talk about scaling Agile and scaling your approach or scaling your way of working, there's multiple factors, there's multiple issues that you're probably dealing with. Because when people think about scaling, they often think about how do we do this on large teams and certainly some of the scaling frameworks like less and safe and arguably Nexus deal with the large team situation and that's important, but there's more to scaling than that. How do you address regulatory situations? How do you address geographic distributed teams? What do you do when you've got a very complex situation? What do you do when you have great technical complexity? And so when I walk people through this slide and particularly executives, the only response I've ever gotten from this slide, from executives and organizations is oh my Lord, we've got all of these problems. We're all over the board and in workshops I'll often ask teams to rate yourself. Where is your team right now and all these scaling factors? And I've done workshops where I've given out this on a piece of paper and asked people to draw the radar chart and then we put them on the wall and it's amazing. Even in people in the same organization and the teams will be all over the board. There'll be some where the situation is very simple. There'll be some where they're all over the place. And we have to come to the conclusion that yes, the occasional team is in these very straightforward situations where we're a small reasonably co-located team taking on a reasonably straightforward problem and some of the simpler methods are geared for those situations but we also have to accept the fact and observe that we have teams that aren't. We have teams that are globally distributed and teams that are large and teams that are medium sized and so on. So a large team will work differently than a small team. A team in a regulatory environment work differently than a team in a non-regulatory environment. A team taking on a hard problem will work in a different way than a team taking on a simple problem. This is basic fundamental concepts. So one process size does not fit all. One way of working will not work for you. Unless all your teams are the same types of people in the same situation taking in the same sorts of problems, one process, one method, one framework will not work for you. So we need to understand that context counts. So there's no easy button. If you're from North America, you probably recognize this ad, one of the, I think it's Staples or Business Depot. You've got a hard problem. You hit the easy button and they can solve it as their message and there is no easy button for this agile stuff. There is no easy button for this organization structure stuff, which is why we get paid what we get paid. It was an easy problem. They'd be hiring people with no skills to do this job. Another thing that I ask people to observe is your organization, and this came out in the keynote today, it sort of came out in the keynote today, is your organization is what's called a complex adaptive system. And we like to look at organizations as teams that are working on this was very clearly coming out in holocracy where we have these teams and every team should be allowed to and should be enabled to figure out their own way of working, to figure out here's what we do. And so when you look at these team bubbles, that's the inner bubble, our internal way of working. But there's also a boundary. There's also this interface to the team, the external way of working. How do I interact with this other team? And I will work with your team in a different manner than your team because you're different people in different teams and you've got different ways of working. And when my team collaborates with your team, we will probably learn something from you. You will probably learn something from us. We will, I hope, internalize that and change the way that we work as we picked up some tips and techniques from you and vice versa. So not only do we have these collections of teams interacting with each other, but all the teams are constantly evolving and constantly changing their way of working. And this is exactly what we're hearing about this morning in the keynote. So we need to embrace this concept as well. And this is a very interesting thing in a lot of organizations because management will often cringe at this concept of, well, what do you mean that all these teams will work in different ways? And I would invite you to actually observe what really happens. Even in organizations where you have a repeatable process and CMMI and whatever it is that you're doing, the teams are still working in completely different ways. And they might be faking the process, they'll be faking the process in similar ways and making it look as if they're working in the same way, but they're really working in their own ways because they're unique people taking on a unique problem. So let's embrace this and let's enable this. Let's help teams be the best they can in the situation they face. Let's help them improve and get better and let's make this easy and make this desirable to do. Why wouldn't we want people to learn and improve and get better and become more effective at whatever it is that they're trying to do? So in the toolkit, we look at the overall picture. So one of the things we see in many agile transformations and Mark and I are gonna talk about this tomorrow in another talk is that a common mistake that organizations make is that the only focus on software development, they'll only focus on adopting Scrum or adopting Combon and then applying it in their software development teams, which is great. But we need to observe the fact that there's other parts of the organization and that these other parts of the organization are working in very different ways. So if my team is trying to be agile, but their procurement folks are very non-agile or the finance folks are very non-agile, it pretty much shoots us in the foot, right? So we all need to be working and learning and getting better and working in this flexible learning approach. So the overall, so today, my focus is on the bottom layer of dismantling agile delivery, but the principles and the strategies all apply at these other organizational layers or organizational process areas, call them whatever you want. So one of the things we like to, one of the ideas that we like to promote is this concept called guided continuous improvement. So how can we up our game? How can we help teams learn and improve and get better? So a lot of things that we hear about a lot, like teams should own their own process. Well, how do we enable a team to own its own process? I think is a very, other than just saying, you're empowered, Phil was talking, but this earlier, you walk in, you talk, tell a team, congratulations, you're empowered. Well, that's meaningless, right? You've got to help them become empowered, give them the tools to help them do that. So I'm Ivar Jacobson, and many of you might know him, he's one of the three amigos that gave us the UML and he promoted use cases and unified process and many, many good things and sometimes not so some good things, but he's recently been writing about this concept called method prison. And what he's observing, and what's certainly what we've been observing and it's wonderful that he's given a term to it is that teams and organizations are finding themselves in framework, this framework or method prison where they're constrained by the methodology, by the mindset that they've adopted from whoever it is that's promoting that framework or that method. So maybe it's time to break out. So, although having said that, to be fair, adopting a prescriptive method makes sense. I'm sure many of you have seen this curve where what happens is when you adopt this new idea, you take a productivity hit at the very beginning. So you'll adopt scrum, you'll adopt safe, adopt combine, you'll adopt whatever and there's a little bit of learning curve and you're not quite as effective at the very beginning so you take, there's a dip in productivity and if things work out well, then everything gets better and you improve but then you hit the limit. So scrum takes, tells you about whatever it tells you about it's saying and combine, it's got it's advice. So it solves the problem that it solves and then you sort of peek out. And this is a very common pattern. But to be fair, things have gotten better. So this is probably good. So one of the things we've noticed is that there's a lot of interesting promises. Now this is a great book. I don't know if this is Jeff Southerland's latest book and I don't know if you haven't read it, you should, you might want to take a look at it. It's pretty good. But look at the cover. He's promising, he's effectively promising four times productivity. Do twice the amount of work and half the time. Two divided by one half, it's four. Four times productivity. That's a wonderful promise and a lot of people buy into it and that's great. And I've certainly seen improvements like that. If there's a phenomenally dysfunctional team, then yes, almost any type of change will help them improve. I've literally, a couple of years ago, I worked with a team. We improved, we changed the coffee that they had and I would swear there was like almost a 20% productivity increase almost instantly by getting rid of the crappy coffee and producing and replacing with something drinkable. So certainly, if you've got a phenomenally dysfunctional team, you can get pretty good productivity improvements. But I'm also a firm believer in numbers and there's a fellow by the name of Don Reifer. I don't know if you know him or not. If you don't, you should get familiar with some of his work. He did his PhD in Agile Transformations and he basically asked the question, how effective is this Agile stuff? What types of productivity improvements are we actually getting? And what I find interesting about Don is that once he finished his PhD, he turned it into a business and he now, he coaches and he works with organizations around the world and he's also continuing his studies. So he's got data from, what is it, 3,500 teams? I think it's 3,500 now, this data's a little bit old, but certainly over 3,000 teams. So this is statistically significant and what he's seeing is that he's seeing a 7% to 12% productivity increase. So he's seeing a line that looks like this, the type of line that we've been talking about for years and he's actually got data. Now, 7% to 12% improvement, that's good. That's a good thing. I'm not gonna, you can't sneeze at that, but it's not the 300% productivity improvement that we've heard about, right? So, and at scale, his numbers are showing three to 5% improvement, still okay, but certainly maybe not quite as good as we would hope. So I think there's some, a little bit of room for improvement here on the improvement side is good. And what's also interesting is that when you read some of the DevOps case studies, you read about Amazon and eBay and Google and all these companies, they're seeing significant productivity increases and you read some of these DevOps case studies and it's like rocket science, like it's unbelievable. Some of the thing, you talk about releasing into production many, many times an hour and or the Amazon releases into production every few seconds now. And you talk about these sorts of ideas to banks and insurance companies and they can't even conceive it. They can't even conceive that and yet it's nothing for the Amazons of the world. So the, how do they do that? And the DevOps case studies are all the same. They're all, at some point in the distant past, we realized that we were gonna get wiped out if by another competitor, if we didn't get our act together. So they decided to improve and they, sometimes the study, the case study is all about, they thought it was a transformation project. Sometimes they were a little more advanced than that but they very quickly realized that it's a transformation journey and that they, the way that you improve is you make small improvements over time. Exactly what the lean folks have been talking about for decades, you do this kaizen type, small improvements over time add up. So they talk about constantly improving and exactly what Richard was talking about this morning where you feel the tensions, you come up with an idea and you try it out and you experiment and you see if it works. So this, and there's different, there's OODA loops and PDSA, PDCA and all good sort of stuff but there's different, they all boil down in the same sort of thing. So you identify potential improvement and you experiment with it, you try it out in your situation. So just because something worked for some, TDD works for somebody else doesn't mean it's gonna work for you. You don't know, you gotta try it out because there's no such thing as the best practice. All practices are contextual in nature. So just because something works well for this team down the hall doesn't mean it's gonna work for you at all. You gotta give it a try, see what happens. So you give it a try, you gotta give it any long enough to actually assess fairly. So then you make an assessment, how well did this work for us? Did TDD work or what aspects of TDD works for us, what aspects don't? And if you're smart, you adopt the stuff that works well and you avoid the stuff that doesn't work so well. And if you're really smart, you're like, hey, we got another tension, so let's figure out what new problem we need to solve. And if you're nice, you share your learnings with others. You say, hey, TDD worked for us and this is really cool when you offer to coach or help other teams learn this thing that you just did. So this is all wonderful, this is lean one-on-one type stuff, improvement one-on-one type stuff. Now, the issue though is the very first step. And Rich was talking about this morning. You feel a tension, so you come up with an idea and you try it out. Well, how do you know what to try? Because there's hundreds if not thousands of practices out there. So this is where the toolkit comes into play. So the issue is we're not process experts. The very few of us are process experts. So how do you own your own process when you don't even know what's for sale? Like if you don't know, if you're in method prison and you've only been told about the 12 practices of this method or the 15 practices of this framework and you're now a certified master in it, how do you learn about these other potential techniques that might work better for you? So this is what we talked about in the toolkit. So where we see improvement, where we see continuous improvement, like the DevOps case studies and good stuff like that, where we see these improvement lines, the dashed one, and it's not never this smooth, right? It's up and down, it's sort of this bouncy thing, but it trends over time, it turns upwards. You can improve this through making better decisions to begin with. So instead of just coming up, hey, why don't we try this technique and see what happens? Well, wait a minute, we've got this problem, we detect this tension. Here's five or six good strategies that might work for us. Here's the trade-offs involved with them. So let's talk about, hey, we've got five different options. This option sounds like it's more likely gonna work for us. So let's try it. So we can have fewer failures, because we're always talking about failing fast in Agile, which is a good thing. I would rather succeed early. I would rather succeed faster. So if I can have fewer failed experiments, fewer learning, we always spin out it's a learning opportunity if the experiment failed. Well, you know what? I would rather have had the experiment succeed to begin with, and so we can improve the angle of our improvement by making better decisions to begin with. So that's basically what we're talking about with the toolkit. And you can get your way out of method prison by doing this. So if you've adopted Scrum, you've adopted Save for Laster, whatever it is that you've adopted is great. You've achieved some benefit, whatever that level of benefit is. But if you've hit the barriers, if you're sort of struggling to how do we get better now? Well, let's get on this curve. Let's start doing this more of this guided continuous improvement thing. So it can be Scrum plus DA or Save plus DA to help you solve the problems that you actually face. So we can get out of jail with just a little bit of guidance. So how do we keep this lightweight? How do we make this simple and easy for you? So how do we choose our way of working is I think the fundamental question here. Another way to look at it is how do we be a better agile chef? So when, from an agile point of view, we have all these ingredients. Maybe a tester of development and planning poker and user stories and mob programming and pair programming and continuous integration. There's hundreds, maybe thousands of practice. At this conference this week, there will be hundreds of good ideas presented by the various speakers. I guarantee that. I guarantee that. And they'll contradict each other, of course, but it's all good stuff. But how the heck do you choose between all those things? How do you even know about them? Because you can't possibly sit in it, even though we're at this conference, there's four or five other talks going on right now. So you can't hear everything, you can't hear all this good advice from everybody. So we've got to, luckily they're being filmed, so you can look at them later, I guess. But still, we've got an issue. So how do we detect? So the point is there's lots of great practices and ideas out there. And of course we've got recipes. So just going to the market and buying a bunch of ingredients doesn't make dinner. We have to, either you've got to be a chef, you've got to be a cook, you've got to know how to put these ingredients together to make a great meal, or you've got to have a recipe book to follow, which is what these methods and frameworks are all about. The challenge, though, is that you don't want to eat the same meal every single day. So for example, my daughter, I've got an eight-year-old daughter, she could live on mac and cheese. This would be an ideal environment if we were willing to feed her mac and cheese for every single meal, she'd be a happy kid, probably at least for a few weeks until she got sick of it. But anyways, you're not always in a mac and cheese situation. Sometimes you want to have different meals, I'm sure. Does anybody have the same dinner every single night? No, of course, every so often there's some weird person that does that. But you typically don't want to, yet you want to have a variety. Variety is the spice of life. So the challenge with these recipes, with these methods, with these frameworks, they're great, but they give you one answer. They give you, you know, mac and cheese. So for example, this is the scrumbock. I don't know if you're familiar with the scrumb guide. I don't know if you're familiar with this. And this is great. This is like eight, 16, or 18 pages, depending on how you count, of awesomeness. There's some great ideas here, but it's a little bit thin, right? There's a bunch of great stuff, which is wonderful, but it gives you one recipe. It gives you the scrum recipe. And they wave their hands. They say, yes, you can change it up and do whatever you want, but you still end up with mac and cheese, right? So here in this mac and cheese, there's some spice on there. Ooh, you know, big, huge improvement. And yeah, so you can have spicy mac and cheese or change up the cheese. Well, you can tailor the recipe a bit, but for the most part, you end up with mac and cheese. So how do you expand your horizons? Say we're not university students anymore and we're not living on mac and cheese. So how do we do that? So Disponagill is based on seven principles. And they're all, I hope they're fairly common. One of them is the lean concept. We want to delight our customers, not just satisfy, we want to delight them. We want to make them happy. Because if we don't delight our customers, somebody else will, and we'll steal that customer away from us. We want to have awesome teams. We want to have awesome people working on awesome teams doing awesome things. This is straight out of modern, the modern agile stuff. We want to be pragmatic. We need to get away from the purism. It's not about being agile, it's about being better. It's about delighting our customers and being awesome and good stuff like that. So let's do the best we can in the situation that we face. And sometimes that means we work in a traditional manner and that's okay. Context counts, different teams and different situations will work in different ways. And choice is good. So I can't make different types of things for dinner for my daughter if I don't have access to a market. If my market only sells macaroni and only sells cheese and only sells that spice that was on top of the mac and cheese, then I'm still only gonna be able to make mac and cheese. I need to have a range of ingredients that I can then combine in an intelligent manner into something that's editable. We want to optimize our flow. We want to make sure it all works together. Like I was saying earlier, it's no good if we have an agile software development team, but our finance team is still forcing us to do big estimates up front. Or the procurement team takes six months to order a chair for us, for our team room, that type of stuff, let alone other nastiness. And we want to be enterprise aware. We want to do what's right for the company, not just what's convenient for us. We want to look at the bigger picture. So how does this all play out? So I've been talking about a toolkit. So what does this toolkit look like? So how do we provide choice? So first of all, you want to initially figure out what situation you're in, and initially tell your approach to meet the reality of your team and the situation that you face. So a large team organizes itself differently than a small team. And then of course over time we want to reflect, we want to improve, identify attention, let's try to improve on it and solve the problem. So one of the things that we do in Dismantial is we support multiple life cycles. So it's observable in most organizations that you have some teams doing scrum, some teams doing combine, some teams doing other things. So a large team will be following a program type of a life cycle, you'll have some teams doing projects. Many people here work in organizations where you still have projects. How many teams, how many also work in organizations where you also have long standing teams or no longer a project team? And how many have both? Yeah, both, and fair enough, right? And those teams work in a different way. You'll have some teams doing more of a continuous delivery type of a thing versus the project, the scrum project teams. And that's okay. Different teams, different situation, we'll do different things. And of course they might improve over time. We very often see a team start with one method or one framework or one approach and then as they learn, as they evolve over time, the life cycle changes as well because they adopt different practices. So you start adopting practices like continuous integration, continuous deployment, you start moving away from a scrum type approach into more of a CD type of approach and that's fine, this is normal. Nothing wrong with that. Now, what we also do is because in many organizations, management freaks out at this concept of, well, what do you mean all these teams are gonna be working in different ways? Well, we support a consistent level of governance across teams, risk-based as opposed to documentation-based. So let's allow the teams to work in their own way to have their own way of working and yet still have consistent lightweight governance as about motivation and enablement as opposed to command and control. So we can allow the teams to learn and to improve and to change, have this respect, this reality of being a complex adaptive system and still allow them to do their own thing. So we can still have consistent governance so we can still lead, we can still guide yet allow the teams to work in their own way. So we've addressed that issue as well because that's important because if you don't have a coherent governance strategy, your organization's not gonna go for this, allow the teams to do their own thing, message and nor should they. So how do we do this? So when we put the toolkit together, we started noticing, so this is all based from practice and from observation because we've got the privilege of working in dozens of organizations around the world and adopting and working with others as well. So these observations are effective based on hundreds of peoples of experience and even though it's easy to observe that these teams work in different ways, at a high level they're all achieving the same basic process goals, the same basic outcomes. So at some point you had to do something like to put the team together, for example. You have to do some initial scoping and continuous scoping. You've gotta think about architecture issues. I hope you wanna grow your team members and help them learn and get better and improve. I hope you're governing your teams. I hope that you're doing risk management, addressing risk throughout the life cycle or throughout the effort. I'm sure you deploy into production every so often. So all of our teams are doing these things and more at a high level, but they're all doing it in different ways. So my team deploys into production differently than your team. My team explores scope differently than your team because we're different people in different situations. So a team building a data warehouse will explore scope in a much different way than a team building a mobile app. Pretty basic concept. So one, you know, scoping size does not fit all. So to dive down into the details, so this is wonderful advice at a high level, but not a lot of good low level advice. So how do we actually choose our wow? So what we do, we have this to simplify things to make it straightforward. We have these things called goal diagrams and it takes about five, 10 minutes to learn notation. It's not so, this is the, this complicated as it gets. And it's a little bit fuzzy, sorry about that. But the idea is that when we're forming a team, there's a bunch of process decisions that we need to make. How big is the team gonna be? Where are these people coming from? How available are they? Are they 100% on the team? Are they part time on the team? How distributed is the team gonna be and so on? So there's a bunch of important decisions that we need to make. And we will make these at least implicitly if not explicitly. For each of these issues, there's options. There's different ways that we can geographically distribute the team. It's not just about co-location, it's not just about global. So, and then behind all this, we work through what are the, so not only do we describe the options, we say here's the trade-offs that you're making. So now you can make intelligent process decisions. You can identify ways to address the tensions that you face and choose better, make better choices. This is another example of a gold diagram. So in behind all those bubbles were diagrams like this. So how do you use this? So when we go to explore scope, it's not just enough to have a list of options. We also need to understand what these options are. So say for example, we decide that we wanna do personas. And we don't know anything about personas. So we can look it up, here's what our persona is all about and here's the trade-offs that you're making. So now you've got a better idea of will personas work for us? And then if this is not enough detail, it might not be. Then you can follow the link and read more about personas. And because there's wonderful articles and books out there about personas if you wanna learn more. So you can start making better decisions. So we can use the toolkit to look up these practices to help us understand what our options are what trade-offs are we making. So that way we can make better choices. We can do this in retrospectives. We can do this in initial tailoring sessions when we're identifying our process to begin with. And certainly then we want to run experiments and find out does this actually work for us? So we can move away from just having mac and cheese to at least now if we're gonna eat pasta because my daughter loves pasta nothing I can do about that at least we can change the pasta up and have something a little better for date night. My wife certainly won't tolerate having mac and cheese for date night. It's gotta be some sort of fancy thing at least. So we can have different meals on different days and that's okay. You have the right meal, have the right process for the situation that you face. So just to wrap up here before I go to Q and A. I wanna leave it, it's not about just about dispensable, it's not about dad. So it's not about dad or safe or dad or scrum. It's really about dad and scrum or scrum and dad or safe and dad. So this is the way we can evolve our way out of method prison, how we can improve our ways of working. So instead of having all this rhetoric around yeah, if you're doing this method, yes, of course you can improve and tailor to meet your own needs but then getting no advice. This is a good source of advice. So anyways, there's a lot of great stuff in the toolkit if you're interested. So just to wrap up here, any questions or any answers? Answers are good too. That gentleman there. But in the proposal, you might have to give some visibility and transparency not only to the end goal but also to the way your strategy is for the transformation. So how do you foresee what your strategy might be for the transformation? Okay, so to repeat for the film, the question was, so you're doing a proposal or you're at the beginning of a project or beginning of a team, how do you guess? How do you know what to do? So you've got to ask what the situation is and this is a bit of an experience thing but it's also, worst case you can look it up I guess but you've got to understand what the problem that they face so you've got to understand this is a globally distributed team, it's regulatory, they're taking on this sort of a problem and you do an initial tailoring and make an initial guess of this is the approach we think is gonna work but I would assume that we will learn and we will improve as we go and that the process has got to change. So the process is not carved in stone. So part of what we pitch is that we're taking, we're gonna start off with the best guess we can knowing the situation as it stands today. We also know the situation will change. The requirements will change, the technology will change, the people involved will change, the priorities will change, we will learn as we go and so on so there's all these changes so it's a complexity adaptive system so we assume the process is gonna change as well, the approach will change and that's what we pitch. So then we're not, because we wanna do the best we can in the situation that we face and always try to get better. So that's how we sell it, how we pitch it. Some people like that, some people don't. It is what it is. Sorry, oh yeah, another question. Matt, gentlemen there, actually just wait for the mic because you know. Hello. Hi. So my question is here like when we expand our team from one sprint to different, different stream. So how this wow factor can be achieved if we are on one particular sprint, the pressure is there. We're expanding the source to handle the pressure. At the same time how this wow factor can be achieved inside a sprint or also in a particular, on all project basis. Okay, say that again. Make it concise. So basically how this wow factor can be achieved if we have more pressure on the team to achieve delivers, then this wow factor, how we can deliver any. So yeah, so if I understand your question, so there's pressure on the team to deliver whatever they're delivering. So how can they take time to improve their process? I would turn that around. How can we not afford to not improve our process? We want to get better. So it's a little bit of investment to, certainly a little bit of investment to do a retro or to do some sort of learning and to say, hey, we've got this problem, let's run this experiment to see, we think this other way of working will help, it will help make us better. So there's certainly an investment there of several days or several weeks, whatever fair amount of time it takes. But at the end of that we'll know either it didn't hope it worked and if it did then we've improved. So we've gotten faster, we've gotten more effective, we've gotten better. So it's a maturity thing in some ways but you've got to go at risk, you've got to go on trust that this is good and what happens once you've had several successes like that, then it isn't really an issue. It's that first few times that you do it that sort of freaks everybody out. Got to make our schedule, meet the budget and it's well, yes, but if we continue to work in this slow manner, it's gonna be a lot harder than if we choose to try to speed up or try to get better. So yeah, it's a bit of an investment. Thank you. That gentleman over there. Hi, you talked about the improvement that Scrum and Safe brings in seven percent and five percent, how does that helps? Is there a comparative study where in the same organization, a part used DAD and the other one used Safe, how did it go? Is there anything like that? Yeah, so I'll go back about 50 slides. Yeah, so the idea is that there's no magic here, right? So there's, we choose to observe what's worked. So we've seen in all these organizations doing DevOps, what actually worked and what actually helped them get better was this continuous improvement over time. All the case studies are the same and I would invite you to read them. They're all the same. The message is always continuous improvement. We've been doing this for years. This is why we're doing all these awesome things now and then, so let's get on that path. So the challenge with these prescriptive frameworks, these prescriptive methods, they're great stuff but you hit their limits, right? So once you've exhausted the 18 pages of Scrum, it got you the improvement it's gonna get you but now you gotta look at something else. And same with safe, same with less. They're all great at what they do but once you hit the limit of that, then how do you get beyond the limit, right? And their advice is always the same. It's always, well, fit your smart, you can figure it out and yes, you are smart and yes, you can figure it out but when you do it on your own, you end up on this sort of a curve and most of the DevOps case studies are on that sort of a curve. Still good, you're still improving. That's awesome but we can do it faster by having the humility to understand that other people have solved these problems before us. We don't need to reinvent the wheel. We don't need to figure these things out. This is why we have conferences like this to share all this knowledge, share all these great ideas. So all we're doing in DA is sharing those ideas and we're saying, hey, you know what? Instead of the 12 or 15 practices of Scrum, here's the 500 practices of DA. You choose the ones that make sense for you. So let's get on, at least get on this path, break out of method prison that way but we would suggest, you know what? It's worth your while to pick up a book and maybe see that you've got some options and hopefully get on this path because like I said, the challenge is this first step. Unless you're a process expert, you're just guessing and you might, it may be if you're out there Googling things, maybe you'll find it but you might not even have the language to go search. I see this all the time and they once, because once you're in method jail, you've got the terminology of that method and that framework. Well, what about all the knowledge that's outside of that framework? If you only use Scrum terminology, you'll only find Scrum information, which is fine but we could have the humility to understand, you know what, there's other sources of information that might have solved some very common problems. Like last night, some of the, you know, at a speaker party, some of the speakers were discussing architecture and agile and why people are still struggling with a basic concept that got solved 20 years ago now and yet we're still struggling with it because often people don't even know how to go search or if they do, they might not even have the terminology anymore to search for the wealth of information out there about lean and agile techniques for architecture. So anyway, so it's worth looking at I think. Do we have time for any more questions? Maybe one more. Any other questions? Okay, well thank you very much. Hopefully this was of value to you. Thank you.