 My name is Scott Ambler and this is Mark Lines. So we're going to, our presentation today is about how do you create high-performing organizations. So if you happen to have been to my presentation yesterday, that was about high-performing teams. So now we're looking at the, we're going to discuss the organization aspect of this. And we're working through a theme of the, an old Clint Eastwood movie, The Good, the Bad and the Ugly. So I hope some of you are familiar with it at least. It's more of an old guy thing. But anyway, so who are we? So we're the creators of the Disponential Toolkit. And one of the things that we do is we work around the world to help enterprise class organizations to adopt and to transform themselves and to adopt these agile and lean strategies and to become more effective. And that's basically what we do. We're going to share our experiences doing that today. So I'm going to ask you to think outside the box. Some of the, some of the ideas are a bit radical. One of the, one of the messages here today is that there is no official recipe. Every organization is different. Everybody's journey is different. So if you're looking for, you know, the easy ten step process or the, the cauter eight step method or, you know, you know, whatever, you know, multi-step method you want, there is no multi-step method. So you really do need to do the work and go on a journey, not just a transformation project. So that's one of the things we'll talk about. So we're going to work through in a slightly different order in the movie. We're going to start with the ugly and the bad and then Mark will, Mark will get into the good stuff and then we'll wrap it up and we'll take questions towards the end, of course. So the ugly. So what are some of the challenges that we're seeing with agile transformations? The first one is that these change efforts in general, it's not just an agile thing. In general, these change efforts have a reasonably poor track record. You know, as we're seeing roughly one third of these change management efforts are succeeding. And there's many reasons for this. A lot of it is the people leading the transformations, the ones that are doing, that are, you know, leading these journeys often don't have a background in, in this organizational change management stuff. So they're, you know, in some ways they're making up as they go. So we're, what we want to do today is share some, share our strategies for doing this. And, you know, I think it's important to point out, we, you know, like I said earlier, we do this on a regular basis. This is, you know, what our organization does. Yes, we, we share the dispensable toolkit with the world, but, you know, our bread and butter is to help organizations actually do this stuff in practice. So some of the challenges that we see in the, in the world are some reasonably unrealistic expectations. This is a, Jeff Southerland's latest book, and this is a great book, you know, please don't get me wrong. This is, this is a wonderful book, and I suggest reading it. But look at this promise here. We're, we're promised, you know, four times productivity improvement. This is the implication of this, of this title. And, and sure enough, some teams do in fact see this. And, you know, I've worked with some very dysfunctional teams, and some reasonably dysfunctional organizations. And, you know, there's a possibility to actually get some, you know, radical improvement like this. But what we're actually seeing, and I want to point out this is, this data is not from us. This is from a gentleman by the name of Don Reifer. And he did his PhD in this topic of basically how effective is Agile? How, how well are organizations doing this Agile stuff? And now he runs the business. He continues to study, he continues to research. So he's constantly updating his data. He's constantly sharing his results, he's selling his results. That's how he's making his money, I imagine. And what he's finding is that we're not seeing this awesome productivity improvements. We are seeing some, which is good, but we're not seeing as much as we'd like. And certainly at scale we're seeing even worse. So we need to, you know, part of our message here is we need to be realistic. And I think one of the reasons why we're seeing, you know, not what we were hoping for is because people, particularly senior management is looking for easy answers. They're looking for, they just tell me what to do. I want to transform my organization this year or this quarter to become Agile and then move on. And there isn't an answer like that. This is a continuous journey of many, many years. We need to become a learning organization and strive to get better all points in time. So we need to be realistic. We also need to understand everybody needs to change. It's not just about the workers. It's not just about the teams. It's about the entire organization. And if there's one common theme that I've heard, at least in the two morning keynotes so far at the conference, is that it's really an organizational thing and everybody needs to evolve, not just the people in the trenches. And it's really about culture change. And as we know, culture is difficult. This is an old quote, you know, culture eats strategy for breakfast. Culture change is very difficult and you can't force people to change. So if you sat in on the morning keynote and the talk that immediately followed, there was some very interesting things being said there. And one of it was you can't force people to do things. You have to motivate them. They have to decide to change. So this is very interesting. So we've seen many organizations try to force a framework on people. They try to force, this is this new agile way of working and just go and do it and that doesn't work. People have to accept. They have to be the ones to make the change themselves. They've got to decide to improve and to change the way that they're working to change their way of thinking. So they have to internalize it. So change can be hard, but it can be a lot easier. Part of our message here today is it can be a lot easier if you understand what you're doing. And I think one of the reasons why we're only seeing a one-third success rate is because we have people that really don't understand how to do this change and they're doing the best they can. But there are a few techniques and a few ways of looking at things that are absolutely critical. And this is what we're going to focus on when we get into the good section that Mark is going to work through. So some of the bad things, some of the questionable strategies. So I'm a firm believer in trade-offs and in understanding what works well and what doesn't work well. This is, you know, for those of you who remember the patterns community and then the anti-patterns community, I was actually one of the people that believed in anti-patterns as well as patterns because I believe it's important to understand what works well, effective patterns, but it's also important to understand effective or ineffective anti-patterns that don't work well. What can we avoid? What are bad ideas that we really want to avoid if we can? So one of the things that we're seeing, which is good, is that Agile, the Agile community, is really good at building software development teams. We really are. We're at the leading edge of this, and particularly, you know, the DevOps stuff when you're bringing technical issues as well. We really are good at building these teams, these racing car engines, you know, and we're good at tuning them and tweaking them and getting better performance out of them and better quality out of them. We really are good at that. But then we take these Agile teams, these great racing car engines, and we plunk them into our organizational tractor, and we wonder why we're not winning the race. Well, we all end up with a tractor with a really cool engine. That's better than a tractor without a cool engine, but it really isn't going to get the job done. So if you want to win the race, if you want to be a truly agile business, then you need a racing car. You need to actually look at the bigger picture, and this I think, like I said, this has been a common theme throughout the conference so far is that, you know, we've got to look at the bigger picture and really be asking how do we transform the entire organization. So to sort of, you know, bring this back to one of the things that we're seeing, from a DA point of view, that we see a lot of organizations, they focus on, you know, let's create Agile, Agile Scrum teams or Lean, Lean Combon teams, you know, at the software development space, and then they really sort of ignore everything else. And they don't focus on how do we bring Agile to finance or to procurement or to marketing or to enterprise architecture or to data management or all these other important aspects of the organization. So we really need to look at the overall picture. So we'll talk about that in a bit as well. So one of the challenges with this chart, and this chart is the big poster for the Discipline Agile Toolkit, and one of the challenges that we see in many organizations is they start looking at the complexity that they face. So in Discipline Agile, we basically hold up a mirror to your organizational complexity and we say, hey, this is what you're looking at, here's the stuff that you're dealing with, and you need to deal with it. And a very common reaction is, well, okay, fine, yes, you know, we have finance, we have data management, we have enterprise architecture and all these other things, they're all important. So let's tell the finance people, just go off and figure out how you're going to do finance and go off and figure out how you're going to do data management and so on, which is great, but if they go in different directions, if they start locally optimizing, so if the finance people come up with their finance strategy and it doesn't fit in with what everybody else is doing, then they still, you know, it doesn't work out. And we see this in organizations today. We often complain about the procurement processes in organizations where we often complain about how finance is doing great harm to the agile teams by forcing them to do these big estimates up front and stuff like that. And so these ideas that make sense to finance are actually quite harmful in many ways to the rest of the organization. The strategies that make sense to procurement in isolation that make sense to them are actually quite harmful to the rest of the organization. So we need to look at the bigger picture, we need to be enterprise aware, we need to understand we're all working together and that we're really part of an overall fleet and we've got to move together. So we need to look at this bigger picture. So just trying to divide and conquer will not get the job done and we see this over and over and over again in the organizations because they are dealing with complexity. And so the one way to deal with complexity is to, you know, break it up into smaller chunks. In this case, that doesn't work out so well. We need to, you know, we need to all move together and evolve and improve and learn together in parallel. Hoping the problem will solve itself. Hoping that, you know, whatever challenges your organization currently faces will go away all on their own. Good luck with that strategy and this hyper competitive marketplace that we're in. I think this isn't going to work out so well. And it doesn't. We've run into several companies that have pretty much committed suicide because they left solving their, addressing their challenges a bit too late. And now they're, you know, they're still sort of alive but it's not looking hopeful for them in some ways. And this is related as well. I'm waiting until there's an obvious crisis. So there's a really good change method called CAUTER, the CAUTER method, if you're familiar with it and it's like this eight step process. And step number one, and it's wonderful, you know, in some situations it actually is quite good. But step number one, it basically boils down to you need to have like a 75 or 80% consensus amongst senior leadership in an organization that you face a crisis. And until you achieve that, you know, you're probably going to struggle to, you know, go through the rest of the step. So you have to have this common understanding that you're in crisis. But unfortunately the marketplace moves so fast now that by the time you realize that you come to this agreement amongst your leadership that we're in trouble, it's probably too late because now you don't have enough time to react. Right? So you've got to be constantly monitoring, constantly, you know, constantly evolving and constantly changing. So this is a bit of a challenge. Also a common theme from the keynote is that, you know, senior leadership knows best. And it's simply not the case that people doing the work are the ones that typically know better. And, you know, part of the theme from the keynote this morning is not to have bosses at all. Not to have these senior leaders. That everybody is a leader. That everybody should be making important decisions within the scope of their responsibility and accountability and all kinds of stuff. And then of course, believing you can transform quickly. This is culture change. This is behavior change. This is skilling change. This takes time. This takes many years. This is a multi-year journey. And yesterday if you attended my talk, I talked about how if you read the DevOps case studies about how these organizations like the Amazons of the world and the eBay's of the world and Spotify's and all this stuff have achieved these awesome results. And they're doing things that are often, almost impossible for your organization to even imagine doing. And they're doing it on a regular basis as if it's basically nothing. And they didn't get to this point just by snapping their fingers and running a transformation project. And a few months later they were awesome. All the stories are the same. It's been a multi-year journey, 10, 15 years sometimes, of a series of small improvements of, you know, run an experiment, see what happens, and improve. So this is a very common thing that we're seeing in these organizations. And all these DevOps case studies are all the same in that respect. So if you're looking for an easy... I've said it before, I'll say it again. If you're looking for an easy recipe, an easy way to do this transformation, there isn't one. And you will more than likely cause yourself significantly harm by trying to do an easy, quick approach. You will probably make the situation worse than what you're currently faced by going for the easy route. Assuming there... Another challenge is assuming everybody wants to change. You know, when your organization is hundreds or thousands or tens of thousands of people, everybody's got different visions. They've got different priorities. They've got... Some people are very happy working in whatever way they're currently working now. They don't see the crisis, or maybe they see the crisis and don't really care, or it doesn't affect them, they believe. So they don't want to change. So not everybody's going to want to make this improvement journey, and yet you still need to help them. An interesting challenge that I'm seeing amongst some of the transformation coaches these days is this idea that, well, if this group over here is really hard to work with or doesn't want to go, why the heck with them? You know, we won't do the hard stuff. We'll just pick the low-hanging fruit. We'll work with the easy groups that want to change, but this group over here, the finance group, or the data management group, or whatever group of people that is, because they're pushing back and they want to be difficult, we're not going to help them at all. Well, that's basically ignoring a serious problem and that will not solve itself. That's going to be a reasonably bad thing for you. So we need to help everybody and understand that not everybody might want that help, and there's different ways we're going to do that. We also see organizations, and this is part of the looking for the easy answer thing. We see organizations adopting a method or adopting a framework, not because it makes sense for them, but because other organizations are doing it over and over and over again. We see companies basically say, hey, what are the people down the street doing? Therefore, I should do it too. This is the level of thinking that we get. And just because other people are doing it, first, did it make sense for them? Maybe, maybe not. You don't know, but even if it did make sense for them, it doesn't mean it's going to make sense for you. Because you're a unique person, in a unique organization, your organization is unique, your team's unique. You need to do the right thing for you, not just copy what everybody else is doing. And if you copy what your competitors are doing, you're an also-ran. You're not competitive. You're not innovative if you're doing the same thing your competitors are doing and you're guaranteed to fail in the new world. So we've got to be a little bit smarter about this. And then finally, we need to realize that there is no plan. Yes, you want to do planning and do a little bit about front-thinking and get going in the right direction. But we need to recognize that this is a, this is like driving in Bangalore. You're going to be going all over the place. You know, there's not a straight-line way to get anywhere in this city. And that's the same sort of thing when you're planning a transformation. So just imagine that you're driving home tonight and that's basically what your plan is going to end up looking like. So anyways, Mark, you want to take it over? Thanks, Scott. Can you hear me? Okay, the back? Yeah? Okay. So that's the bad. And I'm going to talk about the good. So first of all, I'm Mark from Calgary and I just want to say this is a real treat for Scott and I. We actually don't have many opportunities to speak together. He lives in Eastern Canada and Toronto. I'm in Western Canada in Calgary. It's a four-hour flight and we independently travel all over the world. So this is good fun for us to actually be on the stage together. So I'm going to talk about the good. I should also say that yesterday, Scott did a talk on choosing your wow, choosing your way of working, which is based on our latest book. Just came out. We're really proud of it. It replaces our first book from 2012. And it's about building those high-performance engines. It's a toolkit full of strategies that you can use to supplement whatever technique you're currently using, whether you're using scrum, lean, XP, save, less. Regardless of method or framework that you're using, those methods are not comprehensive and you're going to have to figure stuff out yourself and you can fail fast on your journey to learning or you can pick strategies from the toolkit that are based on certain contexts. You can find one that matches your context. That's going to improve your chances of success. You'll make better decisions. You'll have better outcomes and you'll be more successful much quicker. So that was yesterday's talk, Building High-Performance Teams. Today we're talking about our third book, which is the Executive Guide. It's about optimizing, not at the local level, not optimizing teams, which is this. This is the delivery aspect, but optimizing the organization itself. That is, if you just concentrate on building those high-performance teams and ignore these other areas, you will fail. Because finance and security and release management and data management and enterprise architecture and PMOs, they have their own ways of working. And by the way, those are smart people. They're doing things that what they think is the best way to protect their interests in the interest of the organization. But the problem is that there's a mismatch between traditional PMOs, traditional enterprise architecture authorities and the way your agile teams are working. So what you need to do is get out there and educate them on the new ways of working. They're smart people. They're good people. They just haven't been told what the options are. When we started with that, it was about the delivery team level. And over the last seven years, we've gone upscale throughout the entire organization to help you get better at all these different areas. So I encourage you to look into the toolkit, whether it's governance, PMOs, release management, DevOps. Lots of great ideas inside toolkit. So what I'm talking about here now is this comes from chapter seven of our executive guide. And what we're doing here is we're actually kind of sharing our crown jewels. We're sharing with you how we do transformations at companies. Now there's a difference between a transformation and an adoption, right? A lot of mistakes people make is they take a large-scale agile framework and plop it down on an existing organization without doing the hard things, without doing the necessary transformation. And if you just do an adoption with a large-scale agile framework, it may seem like it's working, but it's going to fall apart over time. So what I'm talking about is the need to actually do a true transformation. And what you see here is the top... This is our roadmap. It's in the book. And the top part of it talks about enterprise coaching. So when you hear about it coaching, there's team-level coaching, but there's also enterprise coaching. And so we have different types of coaches, right? So at the higher level is the enterprise coaching where it's a long-term thing and you do things... I won't talk through all these bubbles. You can read about it later. But we also have team coaching. We can get you through some of the things on this diagram, but we don't have time to talk about them all. So the subject of this talk is essentially how to do the transformation. Now, this picture is also in the book, and it talks about your effort. It's a multi-year effort, and the effort that you put into your transformation activities will vary depending on where you are in your transformation and who you're working with. So I won't go through the details of this because this could be an hour presentation just by itself. But you can see here it includes things like executive education. I'm going to talk a little bit more about that. Your agile training of the team's management. What about the folks in the middle? They need to be agile as well. And by the way, that's a lesson from the trenches that if you don't spend time with your agile managers, you're probably going to run into problems because they're going to be scared. Is there a place for me in the new organization? And yes, there is, is the good news, but you need to educate them on what their new role is. And if you don't engage with them, they will actively undermine you. They will. Because they are under threat, and the only response is to fight back. They can either flee or fight, and they almost always fight, and they're pretty good at winning. Yeah, and we're not perfect. This is a journey for us as well, and this is a lesson we learned, is that my personally in the past have ignored the middle layer too long. But now, of course, we don't do that. In fact, if I go back to the previous one, there is a place that talks about, you know, educating your middle management really, really important. Okay. It's also important in your transformation that you understand who your agile champions and sponsors are, and we recommend that you have a product owner that helps you prioritize, just like on a Scrum team, helps you prioritize where you're going to do your transformation, where you're going to focus your efforts. Now, one of the things that Scott, I'm going to talk a little bit about this in a second, but Scott talked about Cotter and these structured change management methods, and they're really, really good. But the problem is if you use Cotter, add car, whatever it is, often they used to be, and sometimes still are, rolled out in a waterfall fashion. So it's like this month, we're going to deal with that PMO, and next month it'll be architecture, and then next month it will be release management. That is not the way to go. What you want to do is pick the low-hanging fruit from each of those areas and work on them little pieces simultaneously. But you need a product owner to help you understand where you should be spending your time. You need to have that on your teams. We typically get started by doing a very short assessment. We're not big fans of going in and doing a two-month assessment, charging $200,000 and all that. We actually find that we can get a good idea of what the challenges are that an organization faces in three to five days. And yes, maybe we're missing a big sales opportunity, but that's not the point, right? We want to get in and get busy as quickly as we can. An executive workshop, extremely important that you get your executives on board before trying this transformation. If you don't, you're not going to succeed. And it's the same idea where the authorities like Enterprise Architecture and Release Management PMOs are good people, but they just don't understand the new ways of working. You can say the same thing about executives. I mean, they got to be executives not because they're dummies. They're smart people. But often they don't understand the new ways of working. So what we do is we have some workshops with the executives to help educate them that the project-based mentality of the past is kind of from the past and we want to move much more towards a product or release cycle. The annual planning and funding dance that we go through can and should be replaced by more of a rolling wave approach, a much more agile approach. Some of the traditional HR approaches really need to be modernized. And again, they're smart people. So what we do is educate them on the new ways of working, right? And also, let's understand what is our vision for this transformation? What are we trying to accomplish and why are we doing it? And this is an example of a change canvas. You may have seen canvases before. It's essentially putting this vision for your transformation onto one page. And you see here in the middle, I'm going to be referring to the bit in the middle in a second. This is the key vision for a particular company, the kinds of things they want to do. Improve IT delivery dependability. Improve response time to customer needs. Improve quality. Develop high performance teams. And then other aspects of it. What are our success criteria? How are we going to communicate out to our stakeholders? What is the level of urgency? What is the end state that we expect to achieve? Get this, do this in a workshop with your executives, then print it out on a plotter and put it in a public area so everybody can see. Really important. We expect transparency on individual teams. Why wouldn't this be any different? We want radical transparency in the transformation as well. Now this is the exercise that is probably one of the most important exercises in your transformation. It's educating your executives that the things on the left are not as good as the things on the right. And for every organization, this list will be slightly different. So please don't use this. This is a workshop and this is what comes out of the workshop. An agreement from your executive that disperse teams is much better to have co-located teams. Replace the project mentality with the release mentality. Large projects with small. I won't read the list, but you can see part-time allocation of resources to dedicate the team members. In the past, it used to be considered a quote-unquote best practices to have Johnny on 100% utilized. So he was 30% on this project and 50% on this project. And somebody with some tool or spreadsheet says, Johnny's not busy 20% of the time. We need to find a third project for Johnny. And hopefully some of you understand how ridiculous that is because of the cost of contact switching. But we used to think that was the best practice. So we have to educate the executives. There's a better way to go. Really important. When you get, and now this becomes a beacon for the transformation. We print this off, we put it in a public area. Now when somebody says, hey, Mark, we're gonna start this $10 million initiative, I want all the executives in the room to hold each other accountable and say, I thought we said we weren't gonna do that anymore. We said we were gonna go from principle number three, from large projects to small projects because large projects typically fail. And they go, oh yeah, we did say that, didn't we? Let's break that $10 million thing down into a $1 million project and then see how that goes, right? So this becomes extremely important to sort of grease the skids for your transformation. Now in terms of the change management technique itself, now rubber hits the road and we're gonna start to help organizations, we like to use a lean change approach. We didn't come up with this, it's come up by another Canadian, Jason Little and Jeff Anderson. Jeff Anderson. There's a number of people behind this change management method, but it's a marrying of structured approaches with an agile lean approach. So we're using agile to implement agile. Why would we be doing it any other way, right? So I encourage you to read Jason's book, it's quite interesting. He talks about insights, options, and minimal viable changes or MVCs. Insights are pain points. As an example, the team says, oh, you know what, we have to do these detailed business cases that PMO demands that before they let us proceed, it's a 50 page template, it's gonna take a month, why we wish we didn't have to do that? Oh, that's an insight. That's, I always say, are those groups, PMOs and enterprise architects and release management, if you ask your teams, would they consider them to be enablers of your agility or impediments? What do you think, right? I'm telling you, they should be enablers and this is their new mindset that we need to teach them. So anyway, an insight, business cases, they're too waterfall-ish, too bureaucratic. So what we do is, what is an option? Well, it might be several, but one of them might be, let's come up with a one-page business case, a lightweight one-page A4 business case. So what you do is, you don't go into the PMO and say, I'm here to introduce agile, we're not doing that anymore, we're gonna do this. No, that's not what you do. You negotiate with them to say, we have a hypothesis, we believe that replacing that 50-page business case with a one-page is gonna save us a lot of time and money and we actually won't miss that 50-pager. And you know what? Let's try that for three or four projects and if that doesn't work, we can go back to the way we used to do it. That's really important. If they know, you've said in the hypothesis, an experiment, if it doesn't work out, if they know they can go back to what they're comfortable with, they're more likely to give it a try. So that's very important, negotiating the change. You can't shove it down, as Scott said, can't shove it down their throat. So you prepare for the change, you introduce it, you measure it for a while. If it's good, you keep doing it. Maybe you'll learn that maybe there's another option you should try. So experiment with that. Or maybe you roll it back. That wasn't a good idea. Let's go back to what you were doing before. This is the change management process. So a minimal viable change, a very tiny change that maximizes the value while minimizing the disruption. And you can and should be doing several of these at once. This is not a serial one at a time type of thing. Absolutely. And thank you for that, Scott. So what we do is we take each of those changes and we put them on a combo on board. And everybody can see it. No secrets. Just like everybody else, you can see the stuff the MVCs that are in progress, the ones that have been done now are reviewing them to see whether or not they're working. And ones that we've... Yeah, they're done. It's now being institutionalized. Now let's pull another change in. It's classic lean combo. You don't have too much whip, right? Too much work in progress. But this is how you roll out your MVCs. Thanks, Scott. Now metrics. Metrics is an important part of transformation. I can't remember who I heard saying this. It might have been Scott yesterday, but absolutely, you want... The time to start introducing metrics is not halfway through your transformation. It's day one. It's when things are bad. So start metrics when things are already good. And now this can be demoralized into the teams when we show them, gee, we're failing our sprints every time, and we're capturing that as a metrics. But I always say, you know what, that's okay, because we're learning. And you're going to feel really good when those reds start to turn to greens. So start metrics when things are bad. Don't wait. That's a key lesson learned that I've learned over the years as well. Now, we also... I mean, we have a lot of webinars and discipline agile for the consortium. And we've done webinars on metrics on this lean change method. And when we talk about metrics, you don't want to Google top 10 agile metrics and roll them out. You want to do metrics design. You want to roll out very few metrics. And we actually talk about this in our Lean Governance course as well. It's a one-day course. You want to roll out very few metrics and targeted metrics to measure the progress against the pain in the organization. Every organization is going to have different pains. Throughput, value from IT spend, quality, attrition, morale, every organization is different. So if quality is the perceived problem, then roll out a metric initially to measure improvement in quality. So what you see here is we use a technique called goal question metric. This is just one of the strategies. There are different strategies for metrics. OKRs is another one, objectives, key results. We actually like GQM better, but we're all about choice. But we like it. It works for us. So what you see here is a goal might be to improve delivery dependability. That's a goal. Well, what questions can we ask to help us understand whether or not we're improving our IT deliverability? The question might be, are teams dedicated to actually meeting their commitments? Or are they kind of not focused? Right? OK, that's a good question. How do we measure that? Well, we could say the percentage of planned versus delivered work that was actually delivered. Or percentage of time that the team has to dedicate to pulling work off their own backlog. Maybe they're distracted by management activities or another project. So you can actually measure this. So there's examples of metrics. Now what you see here is that, remember the change canvas I showed you? And in the middle there was a vision with the key things that they wanted to achieve? Well, these metrics map to those so we can tell whether or not we're actually succeeding in our transformation. People often ask us, how do I measure success? This is how you measure. So you see here, improve IT delivery dependability is actually the very first transformation goal. It's a measure against your transformation effort. This is a real example from a client where they've actually put all this stuff together on one whiteboard, very agile and lean and small. But you can see here a mixture of a number of things. I took a picture of this because I thought, well, this is kind of neat. A lot of stuff going on here. Bottom left, what you can see is they were redesigning the work spaces for the team. In the middle is a strategy board to talk about their key objectives and key categories. Next to it, the first metrics that they're rolling out. And then the moving away, moving from is the, I showed you an example of that in a previous slide. For this company, I remember there was, I was, this is in the coach's room, the internal product owner I told you about and I was in there having a meeting with him and there was a board of directors meeting that day and they were doing a walk around to the floor. It's a software product company. The board is walking around the floor and they walk into our office and they say, what's going on here? We tell them what we're doing and I remember the board member going up and he looked at these and he was asking us questions about our progress against each of these objectives. It's not really hard to understand, right? But there's a good example of information radiators, transparency being held accountable for what you're doing. Okay, I'm just about done. I'm going to pass it over to Scott in a second. This is a journey. It's not a destination. Transformations, the hard stuff, last typically a few years but then it morphs into a continuous improvement journey which goes on and on and on. So you do the hard transformation stuff but understand that it's going, continuous improvement is going to continue. Now inside this one, how do you organize all this guidance? We organize it into things called goal diagrams or process blades and here you're looking at the continuous improvement process blade and the rectangles are things that you need to think about that help you with your continuous improvement and a couple I want to talk about right now are COPs and COEs and we don't have time to talk about all the details. I want to highlight some things here. People get mixed up between the difference of a COE and a COP. A center of excellence is like your transformation team. They're there typically for a shorter period of time, full-time staff with people as part of an initiative to do your transformation. Hopefully you get some coaching involved to help you out with your COE. A COP on the other hand is more of a longer term construct what Spotify calls guilds. I happen to like that term. I think it sounds like a medieval guild where it's all about the craft and staffed by practitioners and they learn from each other sort of longer term. So there's a difference between COEs and COPs. This is an actual picture of one of our clients and I took a picture of it because I thought it was kind of cool that in a certain area of the floor we had these labels, there's a typo here, just say disciplined agile and continuous improvement. So they put the COE and COPs together into one group and then another group is about the DevOps, integration, CI, CD and how DA can help you with that. So really nice to see this visual recognition of these groups in our customers. So I'm going to do this slide now, toss it back to Scott. Invest in coaching. You know, coaching are accelerators on your journey. They can get you from A to B much quicker than trying to figure it out yourself. Trying to figure out yourself is a time-consuming and very costly prospect. Okay, so coaching can really accelerate your journey. You're going to have different kinds of coaches, technical coaches, you know, scrum kind of coaches, team coaches, enterprise coaches and make sure that they're coaching not just the teams but the other areas in your organization. And with that, I think I'll toss it back to Scott. Yeah, thank you. So one of the themes that is a tad dysfunctional in my opinion in the Azure community is that it's all about mindset. And certainly mindset is important, you know, don't get me wrong. But if you don't know how to do things, you're still sort of useless. And this, I think, we need the skills and I think some of the speakers that Dave Farley was getting at that yesterday, we need the technical skills to do the job as well. We need to know what we're doing. So it's not just about mindset. It's not, you know, mindset is absolutely critical but we also need the skillset as well. So don't buy into some of the easy, you know, touchy, feely fixes stuff. It's all critical but it's not the full picture. So we're firm believers in looking at the full picture. You know, for those of you who attended yesterday's talk, we saw this and when you adopt these prescriptive methods, these prescriptive frameworks, there is value. Like, you know, we saw some industry stats, 7% to 12% and good stuff like that. There's value there without a doubt. That's a good improvement. So when you're successful at adopting these methods, things get better. But like I was saying earlier, with all these DevOps case studies, they're all basically the same. The message is the same. We want to take this experimental approach. We want to try new ideas, see if they work for us. Because every team is different. Everybody, every person is different. Every team is different. Every organization is different. And just because a strategy or practice works well for somebody else, doesn't mean it's going to work for you. You need to try it out, see what works for you, adopt the good stuff, abandon the bad stuff, measure, Mark was getting at this earlier with the lean change management stuff. So the basic message here is we want to be constantly iterating, we want to be constantly experimenting and adopting new ways of working to see what works for us. And the Disponential Toolkit provides some guidance. You don't have to reinvent the wheel. We could have the humility to recognize that other people, other teams have dealt with the same challenges that we currently face. So we could leverage their learnings. We could leverage these other strategies that are proven in practice. And like Mark was saying earlier, by using the toolkit, we can actually identify likely strategies that will work for us in the context that we face. Because we have options. There are no such things as best practices. There's always multiple ways to do things. So let's choose, my philosophy, our philosophy is do the best you can in the situation that you face and always try to get better. So this is what we're aiming at. So what we can do is with a little bit of lightweight guidance, we can achieve better results over time. So instead of trying to reinvent the wheel like we see in figuring it out on your own in the dash line, which works well, but it's a little bit slower and expensive, we can speed things up by making better decisions at the very beginning and running experiments that are more likely to succeed. So we can succeed. Instead of just failing fast, which is a good strategy, we can succeed earlier, which is what we're getting at. So a little more positive spin and we can do this. So if you are in method prison right now, like Ivor Yakubin likes to say, if you are following a process you've either chosen to adopt a method or adopt a framework or it's been forced upon you, okay, fine, that is what it is, but we can work our way out of method prison and get on this true improvement path that we've been talking about, exactly like we've been hearing from all these DevOps organizations. So we can get out of jail free or get out of jail with a little bit of work, I should say. So anyway, so I'll hand it off to Mark again for a little few thoughts. I'm not just for just about our time, so I'll keep it quick here. These are real life examples from some of our clients. Simplify your process, get your stuff out of Microsoft project, get it on walls. Now, I know you all know that. I know that's obvious in the agile world, but this is an example of an MVC, right? You go in and say, hey, let's stop doing the Microsoft project stuff. I know it's agile basics, but all the stuff needs to be prioritized. So there's an example of an MVC. Another one is simplify the process. Get away from long front planning. Replace it with agile, what we call inception. You might think of it as sprint zero. We take a little bit more rigorous approach to sprint zero, by the way, and we call it inception. So this is a real life example of an inception workshop with some story mapping going on, visualizing or exploring the architecture on the left-hand side. And then another MVC might be we need to change workspaces. Let's design new workspaces. True story here. Started with drawings. Went to a furniture company. Prototyped work area on the bottom right. You see that the whole, they've redesigned the entire space. By the way, the manager's offices have been moved into the middle of the floor so that the developers can get the windows. Yeah, so just wrapping up. Yeah, and another common theme at the conference is we really need leaders, not just managers. So today's managers I would hope or everybody I hope would move into a, become more leadership focused. And we should inspire the change. We should be the change that we want to be. So some of the critical ideas you've heard here, you have a product order champion for your transformation and also have a succession plan for your champion. Because this is a multi-year journey. You can't count on the champion and the product owner to be around all that time. They leave, they move on to other things. You can't count on somebody else to take over and to fill in if they decide to move on. Constant communication, absolutely critical. Have these visible walls, these visible work boards. Because he's saying here's what we're trying to achieve, here's what we're doing, here's what's working well, here's what's not working well. Have this constant drum beat. And I find that annoying actually, having to do it, but you've got to continue to say here's what we're doing, here's where we are and just have this regular drum beat with the same message. So you want to repeat yourself constantly on this. Definitely get some good coaching. We're obviously biased because we do coaching, but you need coaches. You need people to help you. Both at the team level, at the enterprise level, at the specialized level as well. So coaching the finance or the procurement people is a different thing than coaching software development people. Coaching the data management folks is definitely a different thing too. And you've got to have a background because if you don't know how to do what you're coaching in, your advice is going to be questionable at best. So this I think is a challenge the Agile community faces right now around the quality of our coaches and not having the background. It was interesting yesterday the presentation started off with how many people here are coaches, how many people raised their hand, and then the next question was how many people are experts in Agile and only three or four people raised their hand? I'll just leave it at that. There's this question here. So anyway, time for a minute or so for questions, maybe one or two questions? One or two? Probably one question. Two minutes. Okay, question. Good question. How do we measure the readiness of the client for a transformation? That's why we start with an assessment. We're going to go out and talk to stakeholders at all levels. Team level, middle management, executives, and help them understand if they have the right mindset to address the change. You know, Scott, one of the antipatterns is waiting until there's a crisis to do with the transformation. But I can tell you that often that's what starts the transformation. We get the call to say, Mark, help us. We're not competitive anymore. And then we start... We're willing to walk away from a transformation if they're not willing to do some of the harder things. For sure. A framework? Yeah, we talk about it in our executive guide. You can find it on Amazon. Standard is probably the wrong word. For example, we've got several flavors of doing the assessments. Like a workshoppy type of thing versus an interview type of thing. Because you've got to judge the existing culture of the organization. We'll guide the decisions in what type of assessment will work well for them. And as well, what are they willing to actually work towards? We are here for the week. So don't be shy about coming up to us. Look for the blue shirt or the white shirt with this ponage on it. Be happy to answer any questions that you have over a team. I'll be blue for every other day than today. One more question, maybe, quickly. Everybody has to become agile. It is not only the delivery teams. So when new management approaches to you... So that happens in the stage level or everything is addressed at one point. It takes a few years, I understand. But how do you plan for it as a coach? I mean, how do you suggest them? Some of his catches catch can. But you've got to realize that if we're helping a team here and they interact with five other teams to get the job done, then part of the strategy has got to be these five other teams have to at least become agile enough to allow this team here to succeed at becoming agile. Or they have to be willing to get out of the way. So that's the logic. You've got to sort of eat the elephant one bite at a time. My key point would be, yes, exactly. It's a big elephant. And you need to understand which are the highest pain points and get low-hanging fruit. Go after the biggest pains in the organization and take a lean approach. Don't take a waterfall. Try to design the entire transformation up front. Find the pains and just deal with them and pull your ability to do change as you have the capacity to do so. And you will find after a couple of years the organization is a completely different organization than it was before you started. It's one of the reasons that we're so passionate about what we do is by the time we leave everybody's happier. There's a gentleman over here that worked with me in the United States at a large pizza company and one of the things I helped them do was get rid of time sheets and time tracking. Anybody here love time tracking? No, no more. They don't need to do them anymore. They're just increasing the joy of both finance and the teams. That's just one simple example. So it can be a lot of fun. So thank you very much. We will be around. We're easy to find online if you can't find us when we're here. Thank you.