 I suspect a few more people walking through, and that's OK. So my name's Scott Ambler. I'm one of the people behind the Dispenangelo framework. I'm one of the co-authors of the little book that hopefully all of you got in your conference bag today, or whenever you came. And what I like to talk about is beyond really good, I'm going to talk, I'll mention Dispenangelo every so often, but this is not an overview of Dispenangelo in any way. What I want to talk about is what are the types of situations that we're facing in today's enterprises? So Dave Thomas' keynote today was a great tea up for this talk. He brought a little bit of reality to the conversation that we don't hear enough of. And so anyway, it's not going to share what we're seeing and how to actually deal with some of these problems. And there's no easy answer, by the way, other than you've got to know what you're doing. You've got to do a lot of hard work and suck it up. OK, that's it. And something that Jess was talking about earlier today, it's a lot of hard work. You've got to do it, it's going to take a long time. You've got to make some investments and get into it. So if you're looking for easy answers, go down the hall, there's some people selling you a process framework that'll give you easy answers. So I'm going to ask you to do a little thinking outside the box. If you're new to Agile, this will definitely be a bit radical. If you are very experienced with Agile, probably also a bit radical. I'm a firm believer in empiricism and observing what happens in the real world as opposed to the marketing rhetoric that we often hear. So let's talk about reality. And I'm also going to cover a lot of ground. So I hope a few people will be bleeding from the ears by the time I'm done, because there's a lot of great ideas here. So let's get into it. So first of all, what is this easy Agile thing that I'm talking about? So I like to look at when my company goes in to do transformations and help organizations get better. I look at two factors here. So first, how pro-Agile or how pro-improvement or pro-lean are they? How willing are they to change and learn and get better? And then, of course, how skeptical are they? And are they willing to? Are they open-minded enough to do agile stuff? And easy Agile is in that top right quadrant, where we're selling Agile to the true believers who believe in this stuff, they're willing to change, they're willing to experiment, and that's great. Yeah, that's easy. That's an easy situation to be in, good for you, if that's your situation. A hard Agile is when we're working with very skeptical people, people who have different religions that are not agile, all these traditional folks, or in some cases, the PMI folks, or the data folks, or many others, and people who also avoid change. They don't want to change. One of the reasons why the data community does what the data community does is because they don't like to change. And there's not a lot of new and interesting things coming out of the data world for the last several decades. So anyway, I don't want to pick on them, but they do have a coming. And yet, they need to be agile too. So anyway, so this easy Agile stuff, we don't see a lot of that anymore. Because we're now adopting Agile in banks, in insurance companies, retail companies, automotive companies, these very companies have been around sometimes for hundreds of years. One of my customers has been around in business for over 250 years. So they got a few legacy systems. They got a few legacy people, a lot of legacy culture. And they also have over 1,000 dispensable teams right now. So they've managed to overcome some of their challenges. So they were dealing with, they were in the hard Agile space and they chose to overcome it. Another view that you can take a look at when it comes to easy Agile is the context approach. So we often talk about a lot of rhetoric around small co-located teams taking on reasons straightforward problems. We're working in the smaller, brand new organizations, you know, doing really cool e-commerce stuff using all these new technologies. Well, isn't that wonderful? That's trivial. Those are trivial environments, I'm sorry, those are trivial environments to adopt Agile into. Harder Agile though, is what if you're dealing with geographic distributed teams? Like what are the odds that somebody in India has to deal with somebody else that's in Europe or America or somewhere else in the world? Or we have large teams. So several of the speakers have been talking about larger teams, you know, more than just seven plus or minus two. Some of these complex problems are solved. Sometimes we're dealing with multiple platforms. Sometimes we're dealing with legacy technology, you know, it's a technical debt to pay down. We have technical data debt to pay down. We've got people working for different companies. We're different divisions of the same company. So we're a little bit of politics underway. So these are harder problems solving. This is the reality on the ground. I often go and educate and mentor and coach executives and when I walk them through what we call the scaling factors, this list of hard issues, the only response I have ever gotten from executives is wow, we have all of that. That's the only response I ever get. And it's like, oh, we're screwed. Yeah, pretty much. Pretty much. So what are some of the challenges that we face? One of the challenges is that organizations are complex adaptive environments. You know, so my agile team has to work with a bunch of other teams, which may or may not be agile. So my team, we've got, you know, not only are we doing whatever is that we're doing, but we might have to interact with the enterprise architects. We don't have to interact with the operations people with the portfolio management people, with the support people and so on. It may be worth the support people, but I'll be that as it may. And so what my team does has an effect on what these other teams do and so on. We affect each other. And Dave Thomas was sort of getting at this. I'm early today. All it takes is one of these groups to be going off in a different direction, doing their own thing, or doing something that's different than what we're trying to achieve. And suddenly we got a problem. So let's keep this in mind. Another interesting reality to sort of do a take on what Gartner talks about is organizations are multimodal. And I would ask you to choose to observe this in your company. Right now, if you've got a reasonably decent sized organization, say 40 or 50 people or more, it's not exactly huge. I bet you if I was to walk into your company today and start looking around at what you're doing, I bet you you've got some sort of agile scrum type teams going on. I bet you you've got one or more lean convanish things going on. Some of your better teams might be doing continuous delivering. You might be doing some sort of a lean startup, experimental exploratory thing, something that Jezz Hubbell is slightly getting at in his talk if you were there. And you might even have some traditional waterfall teams. Right, fair enough. So this is the reality on the ground. So for your organization to be successful, you have to recognize that this is the reality that you face. And that you need to be able to support all these types of teams, not just agile, not just traditional. So it's a bit hard on anybody like enterprise architects or management. Anybody has to interact with multiple types of teams. You've got to be able to interact in multiple ways. So I interact with the agile teams in an agile manner. I interact with the traditional teams in a traditional manner. It is what it is, right? If we want to be successful. So as we're doing, and then to make things worse or harder, as you're doing these enterprise transformations, whatever that means to you, at the beginning, you've probably got a lot of traditional teams and a few teams doing agile. And then over time, you roll out more and more agile, more and more lean stuff. So a couple years later, you know, maybe half of your teams are doing some sort of agile, lean type of a thing. But you've still got a lot of traditional going on. And a few years after that, we got more agile, but we still got a little bit of traditional. And that's okay. That's the reality. So as we are evolving, as we're transforming our organization, we got to keep the lights on. So part of the transformation is to respect the fact that you're not only are we supporting this, but this stuff is still underway. And the organization has to make this successful as well as this. That's an interesting implication for anybody who's actually responsible for these transformation programs. And then of course, we have some external challenges. You know, we have security threats. It's often, one of the things I like to do is when I go into a new company, is if I can, I hunt down the security people just to hear their horror stories. One of my favorite questions is how many attacks? How many security attacks are you getting per minute? I'm working with a company that's a retailer now. They get a little over 10,000 attacks per day of people trying to steal money from them or take them down, you know, some sort of denial of service attack or somebody trying to steal money or whatever. Because when you're a retail company, when you're like a shopping, you know, you're when you're, you know, Sears or Walmart or one of these companies, you're dealing with a lot of money. So if you can attack Walmart, if you can break into the Walmart financial system, there's like billions of dollars available to be stolen like that. So these companies are getting attacked constantly. They're gonna have your act together on that. And then of course, it goes to digital transformation stuff. We have disruptive competitors coming into the marketplace. And, you know, we have dramatic political changes every so often. The Americans, you know, elect a absolutely corrupt and incompetent president. You know, they had eight years of good one. And, you know, anyways, what can you do? And worst yet, you've got customers that expect to be delighted. They, you know, they're picky. They want great systems. They want great software. And they're used to it. And worst yet, they're used to going on their phone and downloading a really cool app sometimes for free, sometimes for an entire dollar or two. And here you are, and their expectations are, wow, this software is effectively free. I can get this awesome stuff for free. Why am I paying all this money for this crap that you're delivering? And Dave Thomas had some, you know, interesting cheap shots at IBM and some of the systems they develop and how their, you know, how their stuff is effectively unusable. Okay, and to be, you know, it's not just an IBM thing, of course, but, you know, there's a lot of really questionable software coming out of these big companies these days. And it gets ignored. Doesn't do well in the marketplace. And, you know, that is what it is, right? So we've got a lot of challenges and we have to, we have to rack to those. And we internal challenges. We have politics. We have different views. Not everybody's body's into this agile and lean stuff, nor should they. We have groups within our IT department that aren't well-aligned. IT often isn't well-aligned with the business. We have these traditional cultures. We have often have waterfall governance processes. Almost always. We recently ran a study where we were looking into the effectiveness of governance and what we are finding, how do you govern agile teams? Was it effective to question? How effective is the governance of agile teams? And we found, not surprisingly, that many organizations had traditional governance. So we're still doing quality gates and reviewing documents and all sort of stuff. And that was having a negative impact on the agile teams. Was reducing productivity, reducing quality, reducing staff morale. Negative across the board, the governance approach. It was doing more harm than good. Managed senior management was doing more harm than good in these organizations. But the organizations that were governing their agile teams in an agile manner, they had all positive results. So management was doing good things because management was actually agile. They understood the implications of what they were doing and they bought into the agile stuff. Very important stuff. Sometimes they have overly specialized staff. Dave had a horror story about earlier today about sometimes you need specialists to plug the hole in HANA or SAP, whatever this thing is. Yeah, you do need the occasional specialist, without a doubt. In Dismin Agile, we actually have a specific role for specialists. So even though I was the person that coined the term generalizing specialist, another name for T-Skilled people, we explicitly recognized that yeah, sometimes you need specialists. For the most part, most of the people on your team are in fact these T-Skilled cross-functional on generalizing specialists, but every so often when you've got a really hard problem, yeah, bring a few specialists in, that's a good idea. So we've got to feel a bit smarter about this. We've got a lot of challenges here we've got to become. Our funding processes are almost always a mess in our organizations. We still have this annual budgeting thought process going on in the finance area. That's often a huge challenge. We also have delivery teams working at scale, and we're really listening how I run these executives and I walk them through what it actually means to scale and they say, yeah, we've got all this. Well, a couple months ago, we ran a survey and we asked Agilist, people like you, and when the first question we asked, are you on an Agil team or have you been recently been on an Agil team that you can talk about? If so, then you've filled out the rest of the survey, if not, then thanks and survey ended. So all these people that were self-identifying as working on an Agil team and then we asked them basic questions, like how big is the team? How distributed are things? We gave them a bunch of things, is this happening? Is that happening? Do you have this going on? Basic fundamental questions that anybody can answer. Like how many people are on the team? Not that hard a question for people to answer, right? And what was interesting, we found that in many cases, teams are, people are working at scale, doing Agil at scale. So we have people, one quarter of Agil teams are 20 people or more. So I'm sure you've heard a lot of rhetoric about seven plus or minus two. Well, and roughly half of Agil teams are 10 people or more. And yeah, smaller is better than larger usually. But we have almost three quarters of Agil teams are geographically distributed in some way. So much for the co-location rhetoric. We have 78% of our teams are working in a complex or very complex environment. So we're taking on a harder problem. It's actually interesting, if you look at organizations that have both traditional and Agil going on, they are more likely to be, and these organizations have been doing this for a while, they're more likely to assign the harder problem to the Agil team than to the traditional team. We're finally discovering that traditional does not work well for hard problems and for complex situations. Which by the way, if you choose to read the original white paper on Waterfall, the author of that Winston Wright was tactically to clear that Waterfall would not scale very well. So what was written in the early 70s, we finally stumbled into 40 or 50 years later. Yeah, almost 50 years later. This is an interesting stat to me. And Dave was getting at this early this morning too. In the Agil world, we're often talking about the virtues of whole teams. And I talked about this too, because whole teams are a very good idea. Well, only 4%, 4% of Agil teams are whole. 96% need to work with some other group or some other person in the organization in order to get the job done. We have to collaborate with others. Only 4% of our Agil teams are whole. I wish that was more. Maybe we can get up to 10 or 20% at some point, but only 4% are whole. So maybe we should start observing what's really going on in the industry, as opposed to some of the wishful thinking. So some of the other speakers were ranting as well about some of the wishful thinking coming from the process folks with the self-appointed gurus and stuff like that. So we gotta see the end. One team in six is doing outsourcing now. Either they're being outsourced to or they're on the customer side of things. The one in six. Okay, so all that stuff is not easy. Okay, each one of those points leads you to more difficult situations. Not alone, you've got multiple things going on there. So what's going on? So Enterprise Agil in practice. So how are we doing Agil in these banks, insurance companies, retailers of the world? So a few observations. First of all, and this is one I would choose to ask you to do, if you look around, everybody in this room is unique unless there's some identical twins, I don't know. The interesting thing, if you happen to know identical twins, one of the common factors of identical twins is they're adamant that they're a different person than their brother or sister. I don't know if you've ever met twins or not, but they've got that weirdo thing going on. Rightfully so. So anyways, everybody's unique. So as a result, every team is unique. These teams are made of unique people, so by definition, teams are unique. And we face unique situations. This is a scaling factor slide I was talking about. Just the one that blows the executives away. So we have agile teams of varying sizes. I have personally worked on agile teams of many hundreds of people. And I've worked on very small agile teams and medium-sized teams as well. We have geographic distribution. Yes, we have co-located teams and that's awesome. But sometimes we have people working in cubes or on different floors in the same building or different buildings in the same city or different locations around the world. And yet we can still be agile in those situations. Sometimes they're organizationally distributed. We often have roughly 60% of teams are organizationally distributed. We have contractors or consultants on the team. Sometimes they're outsourcing some of the work. So another organization. And we have regulatory compliance. I think a little over half of agile teams now are working in a regulatory compliant situation. Or we're working under financial regulations or health regulations, like critical regulations. Very, very common. And that changes the game a bit. You have a little more documentation, a little more bureaucracy perhaps in order to be regulatory compliant. Sometimes you have domain complexity. We're taking on hard problems. It's great to talk about simple websites. But you know what? Some people are actually building air traffic control systems and automotive software. I would challenge you to go out and buy a brand new 2017 car that did not have software built using agile techniques. One of the, a very fascinating book is Elon Musk's biography, where he talks about how they work at Tesla. And he is spectacularly clear that the only reason why they're able to be so successful at Tesla and SpaceX and all these other companies that he's got up and running is because they work in an agile manner. That's the only reason why they can pull off this really cool stuff. So if you happen to own a Tesla or you happen to be signed up to be the first people on Mars via SpaceX or whatever they got going on there, you'll be putting your life in the hands of agile software. But anyways, even if you're driving a Ford you're probably, I know for a fact you're putting your life in the hands of agile software at the time. And we have great technical complexity. Dave Thomas was talking about this. We've got a lot of legacy systems out there. We're working on multiple platforms with new technologies and with old technologies. We're reinventing old technologies and old techniques. That's a big, one of the themes that Dave talked today. So anyways, your team will be somewhere on all of these scaling factors and all these complexity factors. Hopefully the easy agile is all the stuff on the left but the further you are to the right on any of these things, the closer you are towards this the harder and harder it is on your team. And your team will have a different set of ratings on this scale than that person's team even though they're right down the hall from you because they face a different situation. So we need to be cognizant of that. So that gentleman's team will work in a very different manner than that gentleman's team because they face different things. So one size does not fit all. If there's one message that you should get out of all this process bashing that we've been hearing at the conference it's not that processes are evil. It's that prescriptive processes are evil. So these simplistic solutions where this is this wonderful methodology and if you only follow these 15 practices and everything will work out well that was great in that one context but you're in a different context. So you're gonna have to think for yourself this is one of the prime messages in this financial you need to think for yourself because context counts. Different teams in different situations will work different ways and rightfully so. So you should know what your process options are and you should choose the practices and strategies that are appropriate for your situation not what somebody's trying to sell you in their book or their services or whatever. So think for yourself. Make good decisions. So it's not that processes are bad it's that inappropriate processes are bad. Big difference. So like I said context counts. So every team collaborates differently. Every team approaches requirements differently. Every team approaches architecture differently. Every team approaches testing differently. Every team needs different kinds of help from other teams really 96% of agile teams need help from other teams somehow and in different ways. Every team approaches deployment differently. So the implication like I said all these prescriptive easy agile take my two-day certification course and suddenly you'll be a master. Yeah that's great. That's a great marketing scheme. Not exactly appropriate in practice. Not gonna get the job done. Sorry. What we do is hard. It takes years to learn this agile stuff for the software development stuff not a couple days or a few hours. This is why we get paid what we get paid. Okay. So we've got to find the right approach and we got a teller approach. And every organization is unique. This is not all the car companies of the world certainly a large number of them. Cars are I would argue a car is a commodity. I can go out in the street right now and a bunch of cars are gonna go zipping by. These are commodity product. You know the automobile companies won't certainly won't pitch it that way. But cars are commodity. But you know what? I don't think it's a stretch to imagine that Ford works differently than Tesla then works differently than Bentley then works differently than Mitsubishi or Cherry and so on. These are all unique companies even though they're all building the same commodity product. So this is the situation. So if you're in an organization I often get from my customers or potential customers before we decide to go on this agile transformation I'd like to read three case studies of a similar organization to us that have already done this. So first of all nobody writes case studies anymore. They're almost always works of fiction when they do. And if you're waiting for three case studies of identical firms, well first of all there are no identical firms to you. And second, even if there were that guarantees you're a follower not a leader. Because by the time the case study gets written and approved by the lawyers and actually published way too freaking late to compete against those guys because they are years along the transformation path now. You know, whatever got published is more than like the fiction anyways and they're years away from it. So this is why you see all these companies being generous with giving out software and stuff like that because they're so far ahead of you they don't mind if you try to catch up. So anyways, we need to start thinking for ourselves. One of the issues we've got so this is a workflow diagram from the workflow diagram for IT from the Disponential Framework. And the way, very quickly over the basic idea here is these are activities not group. So we've got the portfolio management activity, product management, enterprise architecture, got delivery, dev ops in here north of data management part of dev ops. If you're not talking about data stuff and your dev ops strategy you're pretty much in trouble. You know, continuous improvement across the organization and so on. Governance, all those good sorts of things. And the point I want to make is that a couple of points first of all, all these things are interconnected. All it takes is one of those activities to be dysfunctional in your trouble. So you could have a really great agile team and then the governance process is a total mess. And you know, you've got some wacky funding process. You know, you're being forced to do fixed bid or fixed price type stuff. Worst possible way to finance an IT project by the way. Least effective, basically at least incompetent maybe even unethical to do fixed price to do fixed price software development. Bad news stuff. But anyways, but we often get that inflicted upon us by the business because they don't know any better. So what happens is as soon as that gets inflicted upon you a lot of really bad behavior is going to occur on the delivery team in order to survive this bad business decision doing a fixed bid to a price type of a thing. So all this stuff is interconnected and it's going to change and evolve. So if you're truly agile, all these activities you'll be learning, you'll be experimenting, you'll be evolving all the time. So when my team changes the way that we work and we interact with your team, well that's going to have an effect on your team. And when your team changes, that'll affect other teams and so on. So we're constantly improving, we're constantly getting better. It's a completely not only moving target. This is absolutely brutal. This is a brutal observation. If you're trying to coach or trying to transform an organization when it's a moving target. And worse yet, I got slides coming on this but these people don't agree. So behind every one of these bubbles is a book of knowledge. There's a religion behind every single, and it is religion in most cases. We've got the agile religion in the development world. We've got the PMI and print two religion and portfolio management. We've got Togaf and Dodaf and Modaf and Zockman and many other types of religions in the enterprise architecture roles. These religions conflict with each other. They don't agree and they're all at the center of the universe. They have very different and competing vision for how IT should work and they don't fit together. And yet, if we don't get something that fits together, it's not gonna work. It's like it's equivalent of some of these gears are metric and some of these gears are in standard imperial and then we're surprised when they just grind against each other and nothing moves. We've got a serious problem there. So we need to be pragmatic. We gotta get away from this wishful thinking stuff and be pragmatic. And that's what the dispensable delivery or dispensable is all about. It's based on empiricism, based on observations from organizations from around the world of what works and sometimes what doesn't work so well because really it depends framework. We don't prescribe a thing. Arguably we prescribe two things. It depends, think for yourself. Those are the things that we prescribe. So we give you options. So one of the philosophies in agile which is a great philosophy is that a team should own its own process. But how can you own your own process when you don't even know what's for sale because you're not a process expert? And what happens is you fall for these scams where here's my 13 practices and they'll save the universe. Well, no, not really. Because there's hundreds of practices. Pay attention at this conference this week. Count, just do a random count of all the practices and strategies that are being promoted by the various speakers. And they're all great ideas that work in certain contexts, doesn't work in other contexts and that's okay. But there'll be hundreds of practices and ideas that are being floated here this week. And this conference certainly isn't the complete end-to-end knowledge of everything agile. And yet you're gonna hear about hundreds of techniques. We have to pay attention to that. We have to admit that this is happening and we have to admit this is a good thing. But I think it's interesting questions to ask yourself is, well, what practices are there? What are the trade-offs? What are the advantages and disadvantages of each of these techniques? When would I use these techniques? How do they fit together? When should I do them? To what extent should I do them? What's the context of these practices? And that's what this financial is all about. We won't tell you what to do, but we will tell you, here's a bunch, all you need to think about this, here's a bunch of good options and here's the trade-off that you're making with each of these options to choose intelligently. As opposed to randomly guessing what you should do because you read some article. You read a little book and you want to put a certification book. So in order to put everything together, what we do say is that when you're doing, this is a goal, what we call, or this is a mind map. This is a high-level goal diagram for, and it's all on the web and I'm gonna share these slides. You don't have to worry about taking pictures of all this stuff. But we basically say, so one of the observations that we've made over and over and over again is that every team is unique, they work differently and all good for the stuff. So how do you put together a framework that answers, that gives people advice? So what we did, at a high level, people do similar things. So they do initial requirements. At the beginning of an effort, you gotta put the team together. You gotta explore the domain a bit. You gotta explore the technical stretch of it. Dave, once again, was talking earlier about do a little bit of modeling up front. Think through things before you jump into coding. Do some sketching, do some envisioning. He was calling it. Think before you act. Built right into this financial, by the way. And there's many different ways you can think before you act. There's different ways you can envision, but you should do it. You gotta secure funding somehow. You should build some software, some pollution somehow. It was so often you gotta deploy. You should be investing your team, growing your team, helping them learn, supporting them with coaching and training and mentoring, good stuff like that. So from a delivery point of view, from a beginning to end, one of the spear, Jez Humboldt started off talking about water scrum fall, a term coined by Dave West, who was actually the, who wrote the foreword for the first book on disadvantage of delivery. In order to avoid water scrum fall, you gotta look at the bigger picture. You gotta look at it from beginning to end and streamline the entire thing, and not just the middle, not just the construction stuff. So there's 20, the bubbles on the outside edge are what we call process goals. There's 23 of them for, for agile delivery. Each of these process goals breaks up into a decision tree. So what are your options? The way you read this chart, so when it comes to addressing changing stakeholder needs throughout construction, well, there's a bunch of decision points we need to make. How are we gonna manage work items? Are we doing a scrum product backlog? Are we doing some sort of a lean work item pool? Are we doing formal change management? Not such a good idea, but see that it's nice. How are we gonna prioritize the work? When are we gonna accept the changes? How are we gonna interact with the team? How are we gonna elicit requirements from people? And the point is, is that all these decision points, you've got options, so the option list is, now we're not saying we've identified all options, but we are saying we've identified a pretty good range and you might wanna choose intelligently. There's more than just one option. So we're a method like scrum gives you one choice, prescribed one way of doing things. Well, look, there's many choices and there's all multi, you can have combinations. So multiply that, you've probably got several hundred combinations of the way that you can address changing stakeholder needs, not just one, several hundred. And that list is not complete, so there'd be many more. So choose intelligently based on the situation you find yourself in, not based on some book that you were told to do. So as coaches, we have a few things. So when we're, I'm a firm believer in people processes and tools, some of the T-shirt, the first value that manifests to us, individuals interactions, people and collaboration over processes and tools, but all of those things are important. Let's take that to heart. So when you're doing a transformation, yeah, the bulk of your effort is gonna be around people and culture, but you still have to address process issues somehow and you still have to address tooling issues somehow. So from an empiricism point of view, we ran a survey a little over two and a half years ago now where we asked people who had been through these transformations or at least were well down, were a couple years into the transformation at least, and we asked them, so a couple series of questions, one of them was how challenging were these issues? And what we saw was that changing the business culture, adopting technical practices, what also what Dave Thomas was talking about, and Jez Humble as well, going to his talk, and changing our IT culture, these were the top three issues. These were the most challenging things when we were doing a transformation, but still using tools and adopting the management, the scrumming practices, those are also not as challenging, but still issues. But then we also asked how important were these things to your success? And so changing the culture both on the IT and the business side were critical, but adopting the management practices, so the simpler things were perceived to be very critical for our success. So yes, so people, culture issues are important, but you know what, your process issues as well. So we need to address all of these things that want to be successful. You cannot do Agile without tools. You cannot do Agile without practices and processes and things like that, like it or not. It is the reality, and the manifesto was very clear about that by the way. So, what is the implication of this? So when you're actually doing these transitions and you're doing these transformations, yeah, you know what, 80 to 90% of the efforts can be around people and culture, and that's hard, it takes time. Some of your efforts can be around improving your processes and some of that efforts can be around improving tools. Fair enough, right, and then a few tool vendors here that will definitely verify that. But what happens when you ignore one or more of these factors? So if you focus just on people, if people understand how Agile fits together, you'll have people that, you'll have your big group hug every day and it'll be rah, rah, rah, Agile, but they'll have no idea what they're doing. So you gotta get past this touchy-feely coaching stuff. It's important, but it's not the full picture. If we focus just on process, then we'll get cargo called Agile. You'll get teams that are following the practices. Yeah, we hold a 15 minute standup meeting every day, we hold a demo over two weeks, therefore we're Agile. No, you're holding meetings. And if you focus just on tools, you'll get overly complex standardized Agile. So you take what the vendors say with a grain of salt. If you focus on people and tools, you're gonna get kids playing with shiny new toys. See that a lot. If you focus just on people in process, you're gonna get Agile Zealots working in small rooms. See that a lot as well. If you focus just on processes and tools, you're gonna get cargo called Agile that's been well implemented. Or it's been well automated, who cares? You need to focus on three of those issues. If you wanna scale, if you wanna be effective. So what's the implication for our coaches? So what usually happens with these Agile transformations? Why are we struggling so much transforming our organizations? Well, the usual plan looks like this. We're gonna start off with a pilot team. We're gonna stack the deck, get a bunch of smart people taking on a straightforward problem. We're gonna be Agile and we'll declare success. Then we'll start rolling out to other teams and so on and so on and so on until finally everybody's doing Agile. How could that go wrong? But what really happens? Well, we start out with a few Agile teams and it works out well because we've got smart people taking on simple problems. Of course that's gonna be successful. But then we start taking on harder problems and we've run out of A players. Now we're building teams with the mediocre people, with the B players, sometimes even with the C players. And they're taking on hard problems now. So it's hard and hard and hard for them. And until finally, our Agile transformation blows up in our face so we blame Agile, you know, all that good stuff. So how do we avoid this? So what's really happening here? Well, remember that 96% figure where the Agile team, where 96% of Agile teams work in other teams? That's an interesting implication there. So because my Agile team is interacting with the enterprise architect, the opposite people and a couple other teams, well, those teams that we interact with also need to be prepared to work in an Agile manner in order to support my team. So when we're doing these transformations, we've got to not only support development teams, but we've got to support these other activities. So as we roll out Agile to more and more teams, then more and more of the enterprise architect has to be able to work in an Agile manner. More and more of the data folks need to be able to work in an Agile manner. More and more of the operations folks and so on. So where it might take several months to coach a delivery team through all this, it's gonna take many years to coach the enterprise architect because of that transition that we've got. Remember that slide I showed a while ago with at the very beginning, we've got a few Agile teams and mostly traditional and then five years later, it's mostly Agile and a few traditional. Well, over that five year period, those enterprise architects needed to be able to support both the Agile stuff and the traditional stuff. So eventually, assuming that we go 100% Agile, which never actually happened, but if that was the case, then after many years, these enterprise teams would finally be Agile. So this is our hardcore reality that we face. So as a result, we've got different types of coaches. We've got coaches that focus on delivery teams. That's the majority of coaches, but sometimes we have specialized coaches. So for example, coaching a data warehousing team is a completely and utterly different experience than coaching a normal application team. Requires a very different set of skills, much longer term mindset, and sometimes almost always a harsher approach to more of a tough love approach to coaching and the warm and fuzzy stuff. And we need executive coaches as well. That can work at the executive level. That can work with these enterprise architects and the performance folks and the finance folks to help them change their ways, to help them move away from their existing religion to the Agile religion. So we have a different types of coaches. And if you don't have multiple coaches at these levels, you will fail. Just investing in team coaches will not get the job done. That will blow up in your face. It's pretty much guaranteed. It'll be fun while you do it, but it's not gonna get you where you need to go. So how do we transition these enterprise teams? As I was saying earlier, this is the heck of a challenge. Because these enterprise activities, like enterprise architecture and data management, quality and operations, they all have their books of knowledge. They all have their religions. And at Ain't Agile, very different, sometimes very different than what we're talking about. And they believe in that. And they've been doing it for decades. And now we gotta help those people transition. And the way that you coach with the enterprise architect will be very different than the way you coach data management folks with the operations folks and so on. Interesting implications there. And they all have different priorities. And you darn well better understand what those priorities are for each of those groups, because they ain't being agile. Just isn't. They got very different priorities. And those are important things, but all these things are important. Okay, so our overall strategy needs to address that. So from an easy agile versus hard agile, so easy agile being in the top corner here. Well, we have different groups. So some groups of people tend to fall in the easy agile category. Developers and executives tend to really get the agile message. The, about in the middle ground here, we have other groups of people that really might not get the agile message or might be a little skeptical or a little more willing to change. So the project managers, the BAs, the enterprise architects, because they've got their vision of the way things should be. And they're often the most important group of people around and everybody else should just follow their vision. And then in the hard agile category, you got the finance people. You got the governance people. The operations people, not always true. So I'm painting a broad brush here. The data management folks. And they still need to be helped. From a coaching point of view, pretty much a no brainer for the easy agile stuff. And that seems to be the majority of coaches out there just boasting on that. And it's usually just about showing them new ways and helping them to hold in their hands while they do it and helping them out. This is all good. For the middle ground folks, you need to appreciate their issues. Not only show them that there's new ways, but you need to truly understand what these issues are they're trying to address and help them to see that there's better ways of addressing those issues. And then for the people in the hard agile category, not only do you have to understand what they're trying to achieve, you must be able to do their job better and demonstrably do it. Because you will almost always be in a running gun battle with those people for several years. And different people are different. But for the most part, the people, the groups of people that fall in that bottom left hand category, they are very difficult to work with and they've got their own ways. So you must be able to show that you can do their stuff significantly better and even then it'll be a bit of a battle. Just to wrap this up, some parting thoughts. So we heard a bunch of ideas here. Like I said, this is hard. Dealing with these hard agile situations is hard. It's gonna require work, it's gonna require time, it's gonna require investment. You must make this investment. You want to be successful. There's no easy solutions here. We need to accept that this is the situation that you actually face. Like I said, every time I show that scaling slide, all I get is, oh, we've got all of this. Okay, accept that. You've got a serious problem, accept the fact you've got the problem. That's the only way, that's the first step of dealing with it. Stop looking for these easy prescriptive answers. You're going on a two day certification course. I don't even think I could teach you how to be a shoot buying master in two days of training, let alone being a software development master. Sorry about that, right? Start thinking about these things. Respect yourself. What kind of a person calls themselves a certified master after taking two days of training? Right? I'm hard, I'm being harsh and I realize many of you are doing this, but really, my wife is a landscape architect so I get to hang out with interesting people that are not in the IT space and I would invite you to go to another, hang out, spend some time with another profession like lawyers or doctors or architects, people who are responsible, not IT people, responsible people, right? And tell them about how you get certification. They will be horrified. They will not understand how could this possibly be? What kind of a scumbag would do this? I've been in conversations where people cannot believe what is the norm in the IT space. They think I'm lying, they think I'm telling a joke, I'm setting themself up for some big joke. No, no, I'm just describing agile certification. They can't believe that it doesn't take years and years of work and apprenticing and knowledge and training and education in order to become just a novice, let alone a certified master. Everywhere else in the world, except for IT, realizes that mastery takes decades, not hours. We need to go beyond software development. Most of the stuff I've been talking about here is not specific to software. Even though I focus mostly on IT, there's more to IT than software stuff. We need to be prepared to scale tactically and strategically. The tactical scaling is addressing these various scaling factors in the delivery team. Strategic scaling is let's do it across the entire organization. So we're trying to deal with these other issues other than just software delivery. We need to address people processing tooling at once. It's simultaneously and it's gonna evolve over time. We need to evolve our IT teams as well as our delivery teams. We need a comprehensive approach to coaching, not just team coaches, and we need real coaches. Not just some person that put the word coach on their resume or enterprise coach after taking a couple days of training because they realize they can get a better job that way. We've got a higher qualified people to coach us, people with years of experience and they're hard to find. Recognize the stuff we're not journeying on a destination, this is not a project. If you are trying to treat your agile transformation as a project, please stop now. Take whatever money that you are gonna spend on your transformation, just get those bills and flush them down the toilet because that's what you're doing by treating transformations as a project. And at least if you actually physically flush them down a toilet, you've got a good story to tell. And film it and put it on YouTube, you'll get a billion hits, right? So anyway, thank you very much. I'm one minute late, story about that. There's a bunch of great material out there if you choose to read and check it out. These slides will be available, I think I've already made them available. If not, I'm gonna go check later on today and upload them so there'll be a PDF uploaded to these slides by the end of today if it's not already there. So thank you very much and have a great day. I will be available for questions all during the day.