AA127 - Deep Dive on Agile Transformations with Two Agile Coaches

Let me ask you this. Why are we going agile? William's here. Yes. Today in the house we have William Kremner. William is here to bring us his wisdom on all things agile. So we're going to talk about going agile or what that, whatever that means. We'll get into this in a little bit here, but great question. Why are we going agile? Because everybody else is, so we have to, otherwise we'll get left behind. Or maybe our CIO went to a conference. And came back and said, people there were talking about being agile, going agile, doing agile, all of the above. So we should be doing that. I normally don't get cynical until way, like much later in the podcast. Is this the equivalent of all the other companies are going agile. So I got to go agile. He also and right. We have to, because we'll get left behind. We have to do it was. It was everybody was doing management by objectives because Intel said it's the best thing ever. Andy Groves came up with that. And so he just put an "i" in front and it was now iMBO Intel management by objective, it was taught in business schools all over the world and everybody wanted to do it and they did it, in the world was supposed to be magically a better place, except that didn't happen. But coming back to why, why are we going agile? Right. Have we identified a pain point that we're trying to resolve that we think agile will be the elixir for. What are the typical pain points? The typical pain points are usually inadequacies from within rather than, actual pain points. So what about this? Leadership comes along and says, we're always missing our deadlines. It's always costing more than we thought and we're just slipping further and further behind our competition. How about those as leadership centric reasons as to why? Anyway, those are good ones. I was going to say on the, on the, the podcast, I keep another podcast along with Deming, the one that I keep pushing off. They say one I have is with, Tricia, to talk about being the company's first product manager hire. That's that's a big reason I've seen a company even look for product managers is we don't really know how to translate What we want to the developers or we're having all these problems with the you know Things being over budget or over time or whatever and we don't we feel like we're not communicating well With our developers, so we're gonna bring in somebody in product to do product magic it It's arguable whether this is the podcast that really dig into what I'm saying right now, but but the point is it manifests in The the whole agile thing has product managers. We need like a sliver of that Of that magic in to fix our communication with development problem, which has never been a communication with development problem. It's a problem with priorities and roadmaps and things changing and you know business not being clear and a whole bunch of other stuff. I think that segues into, sorry, I think that segues into that other podcast we did on the The business's mission, vision, strategy, etc. If that's not clear, really clear. If that's fuzzy, then you're likely to be on this slippery slope as well. Somebody somewhere figured out that the old adage applies, and it's this. If you keep on doing what you've done, you're always going to get what you've got. And what they've got isn't good enough. So somebody's looking for a better way, somehow, somewhere. And they've heard this phrase, Agile, somewhere, maybe on the news, maybe at a conference, maybe from a golf buddy, whatever. And they're interested in delving into it. Because it just might be the silver bullet they're looking for. So, yeah, so Om and Brian's software development company has decided now, right, we're going agile. So that, that's, that's done. We're going agile. Now what's next? Well, it's probably for those reasons. It's probably for the reasons that William stated. We're not delivering fast enough. Or like we've noticed an influx of competitors and we can't, quickly turn things around as quick as they seem to be turning things around. We may be feeling some pain somewhere too, I feel, right? Like maybe we're, we've got customers leaving us, right? Or our market share is dwindling, for example. There's got to be some pain somewhere that compels you to look at. Wanting to make a change, right? Our stuff's breaking down in the hands of our users. They're downloading our software in the thousands and thousands. Great. But then, also, they're uninstalling our software. Right? So, where's the problem, right? We figured out that. Let's say we know that there's a problem. We need to change. We need to be agile. So, now, how? What's next? How do we become... Well, first of all, what does that even mean that we need to go agile? Right. What does that mean? Does that mean we change a specific part of the organization that works in a different way? Do we change more parts of the organization? Do we change the whole organization? No, no, no, no. You cross out the word PMO. And you put the word Agilist in there and that fixes everything. Or just prefix Agile in front of PMO. Agile PMO. Yes. Yeah, that'll fix everything, right guys? There you go. Right there. I don't think this is fixing things. Oh wait. We need to do more? Do we need more, Brian? I don't, but wait, there's more! There's more! Operators are standing by. That's right, operators are standing by to take your money. I, like the transition from why to how, this is probably the trickiest one, the transition between why to how, because I'm not even certain at this point if we've got buy in. That there is a problem that needs to be fixed.'cause you're get, if, if you're not real solid on this jump, like you're sabotaging like this, this , this is, sorry. It's not cool to not complete my idea. I was thinking about when I built the, when I built my shower, like the, I, I had a wall that was like a, like an eighth of an inch. Maybe it was like a 16th of an inch, like. Not quite flat and I was like, it's all right. I'll figure it out But the problem is that like at the top of the wall It's a sixteenth of an inch that that just gets wider and wider the further down the wall that you go so by the time I got to the bottom it was a big problem and I had to redo it to be flat and I really didn't want to so I took the lazy route and I didn't do it and Everything I did On that project got harder and harder and harder So the further down I go what we're telling everybody is don't come to your house for a shower. Caulking is a wonderful thing. So, so I, having decided that, you want to be agile, go agile, do agile, however, whatever, right. Having decided that, I think many organizations that have not previously considered that struggle because they say, well, how do we do this? Do we know what that means? Right? And they look to the left, they look to the right, and they say, Well, we don't have that expertise, that knowledge in house. So one option is, is to rent. Bring in somebody. Let's bring in an expert to tell us how to transform our business to be more agile. Even before we get there, I think the person that is having this thought at the beginning needs to talk to other leadership within the business and say, if we could find a better way to build our mousetraps, would you be on side with the idea? And we're talking about how, for me, the starting point of the how is getting enough leadership buy in at the conceptual level before you do anything before you go and find an expert or go to more conferences or anything of that nature. So, you build up a power base, so to speak, of, folks across the, the enterprise, who are saying, Well, I'm not sold yet, but if it would work, and if you can show me how it would work. Then I might be interested in supporting it because in my experience, if one sponsor just goes off on their own, without breadth of conceptual thought across the enterprise, then what you end up with is resentment or, well, that's not my idea, so I'm not going to get behind it and politics come into play. So that starting point for me, before you do anything is talk to your folks and say, well. We might have a, the opportunity to build a better mousetrap here if we could go this Agile route. Would you be on side with the play? Yeah, I want to, fundamentally I agree with you, but for now I'm going to take that contrarian view because we are arguing Agile. I'm going to say, let's say we're peers, okay, and you come to me and say, Are you on side with me? We're going to be Agile, right? And I've never really done that. You know, I don't know what that means. I'm going to say, sure, William, I'm right behind you. It's your budget. Go for it. I'm right behind you. Right. I've seen that. That's why I'm kind of taking that, that approach. People will say yes. You'll, you'll get the head nods, but are they really bought into it? And so here's how one might address that. Instead of just saying, I've heard about this thing called agile. It might be the way we can build a better mousetrap. What if I came to you and said. Here's what I think it can do, not only for me and my part of the company, but here's how I think it's a win for you. So a little, a little bit of, proper prior planning prevents piss poor performance. So I... I would, I would be a little bit, thoughtful about how I approached my colleagues and I'd start to tease out what might be in it for them if we went this route. Yeah, I, I concur with that. If, if I can see what's in it for me as your peer, I might be more open to, actually giving you my support, right? But there comes a point where you, as this, Champion of Agile, right, will run into roadblocks and they're not blatant roadblocks. Like I said, people will nod up and down and they'll say, yep, yep, we're right there with you. And then they'll just go back to doing what they're doing. Yeah, absolutely right. I couldn't agree with you more. At some point, you're going to run into, political... Resistance in the organization and the, the champion of going agile has the responsibility, the burden of proof, if you will, of showing the organization how there's a better way. But, I'm, I'm saying this to the viewers, don't think for one moment that this is an easy process. Oh, we're going to go agile and that's it. Get it sorted next week. Next week we're doing agile. Doesn't happen that way. And you don't always get that from the textbooks. Yeah. Yeah. It can take, it can take many months of. Persuading, positioning, looking for advantages to share with people so that they start to buy in. Certainly agree with that. I think as a proponent, initiator or champion of agility. You need to be ready to roll up your sleeves and dive in the icy waters and say, let me be the first one to try this new thing out. And then I'll show you how it works for us and it will work for all of us. Right? So you are the one who is taking that initial jump, if you will. You're taking that, that initial risk of exploring ways to become more agile. And then you can say to the others, look, we tried this and it worked for us. It might work for you. So really, it's it's lead by example, be the first right because you're not going to get everybody on your side linking arms with you. That's just doesn't have a pilot, a pilot program. Absolutely. Yeah, a pilot in a short term and it'll just do the pilot and show results from that and then evangelize it across the org, right. From my experience, It usually, it is the development department or a subset of development department or a segment of the business basically that, that quote goes agile, like bottom up or rallies around some particular leader who runs that just that one department and then they're the one and then agility in the org is a bubble of agility and everything, everything that comes before and everything that comes after. is still the old school method. And then that basically becomes ingrained like that, that, well, from what I've seen, that's most people's. Quote, implementation of whatever that they're, whatever pilot they roll out because it was never sponsored truly at the top, and because whoever is driving the, the, the, the urgency, whoever's driving the need for this change, never really spread the success of the program. Like, it never goes to any other departments. If you are, if you're in a quote, agile team right now, but your finance is still the old, once a year got to beg for money model, if you don't use it, you lose all your money and then your users are going through like a formal UAT phase and , you don't talk to users and also you're not in control of your, who you're, who's on your teams and who can come on to and leave your team, all this stuff on both sides. You're now in a, a real fragile, agile world. Yeah, absolutely. And, just talking about teams for a moment at this early stage, conveying the concept of a cross-functional team and what that means in practice can be really challenging for people to accept, for leadership to accept, because, change is scary. Change implies risk. Mm-hmm. and this idea of restructuring to go with a fully cross-functional team, takes some selling on the part of the agile champion. if you think about that, cause I've, I've, I've thought about this, like around the point in my career where I was like, I don't want to be an agile coach. I'm like, I like product better. You can get things done. People listen, like the, the, like you're relieving immediate pains of the business. And they like it like at that point I, I was like, yeah, I should just stay in product. I like this. I can, I can say that if we don't do this experiment, we, we won't get the knowledge and if we don't get the knowledge, it's gonna cost this much. And I can give dollar figures and it's super easy to do that. I like that. I like that.'cause when I'm throwing money around, When I'm making it rain, that's what I'm saying. When I'm using money, like everyone listens, that's it's much easier. Let me put it that way. It's much easier to state my case. I certainly agree. It is right. But that said, there's no reason why. Agile coach worth their salt shouldn't be able to do the same thing and speak their language. You need to be able to do that. You know, if you're going in there saying, well, we can deliver X number of story points and all that, you missed the mark completely. It's to your point. Talk about everything with leadership in a language they understand, which boils down to only one thing, dollars, right? If you can speak that, an agile coach should be able to convey that message. Listen, I agree with you, but again, here, here we go back to the spirit of, Oh, look, it's like a, we're like a new show where we all argue each other and nobody's makes any points. Like, I, I agree with you. However. The reality is number one. I've seen very few scrum masters I'm saying scrum masters because they're they are the boots on the ground day to day people that should be running with the message if you even if you're in an organization that has layers and you have like Agile coaches up here and they're a matrix or all the whatever, you know talking about. The agile coaches uh Or like the executive leadership, whereas the scrum masters are like the on the ground leadership. Let's pretend in my weird world that I just cooked up out of nowhere for a second that it is this way. Like, the scrum masters are the ones constantly reinforcing the message. And while I understand what you're saying, I have very rarely seen a scrum master proceed forward, translating this message throughout the organization, purely using financials of like, Hey, we should disband this team and integrate parts of it with other teams because even just my team, the cost of delay cost this much. And if we just figure that all these other teams, there's X number times Y amount equals this much money that is wasting having organizational design set up the way it is. Like I've never seen anyone make a case that way, number one. And number two, be successful. Yeah. To your number one, though, you're not going to get people making that case. If you're. Scrum masters are, rebadged project managers. They're looking at utilization. Look, my team is 85% utilized, right? You know, they're doing great, right? They're pedaling as fast as they can, but we're going round and round in the lake. We're not getting anywhere. Right. So you're not going to get that. And this is where, again, if you didn't have, an agile coach on your team, or on your, on your, program, you're going to get these people that simply just have that vision of, this is how we do things. Textbook often called zombie scrum. Yeah. And, and it takes a lot of courage to do what you were talking about, Brian. And in order to have the courage to do this, you've got to feel that it's safe for you to do this. And it's not always safe for Scrum Masters, is it? As we all know. As an Agile coach, you might have a bit more... Muscle to flex in that department, depends on the organization, but I'll tell you this. Both roles require a lot of courage. You're not just following what's on the textbook version of scrum. If you're going to be successful, I mean, I, I've argued many times, like it shouldn't be, it shouldn't shock anybody that the textbook in no way, shape, or form. Or form prepares you for dealing with the, the, like what the scrum guide says, the coaching, the organization and coaching the team, coaching the organization. It doesn't prepare you at all to coach the organization. You know, this is what we're talking about. You can't coach somebody who's completely convinced that they're right. And it was not even open to any, any possible evidence. You know what I mean? Anything could be anything, but exactly perfectly what they're doing as an uncoachable individual. And you have to find ways to either, I don't know, , have three ghosts visit them, on Christmas. And, in lieu of that, I don't know, maybe you go above them, or maybe you go to their peers, or maybe you go to their boss and be like, Do you realize that, they may have some strategic one on ones? To try to, break that armor down, but, The textbook to me is a bit like a, an Ikea user manual. There's no, there's no words. There's just a bunch of pictures, right? And you figure it out. Hopefully you have all the parts you need. Often you're missing parts. But, yeah, as far as the people that are seemingly uncoachable, Scrum Master is not going to have the courage. To go ahead and try different things, right? An Agile coach might try a few different things. We've talked about this on the broadcast before align yourself with their with firms, right? We from wi I fm what's in it for me. So come at it from their perspective. Why are they objecting? Right. Why are they becoming the, the obstacle are they coachable? If you can align yourself with their vision, that's step one to try and like really solve it. Otherwise, you're just going head to head, right? And that's not going to get you anywhere. It'd be like two rams butting heads. If you're a new scrum master or even a new product owner and you are interviewing, For a new position, one of the questions, if you're courageous, you might ask is how coachable is our leadership in the area of agility? How, how open is leadership to change? And I think that's a very good interview question to ask. It shows, it shows, your stuff and that you're forward thinking I was consulting at, an international organization. And they were ripe for enterprise agility. We'd had a lot of success, with the software department, a lot of success with the hardware department, and it was time, it was time to bring it enterprise wide. So I sat with the CEO. And I showed the benefits, and I showed where the monetary savings would be in terms of, operational efficiencies and more effective use of, manpower, personpower. And the CEO sat there and said to me, Well, you know what, William? You're absolutely right. I just don't feel ready for that right now. So, we're not going to do it. By the way, I know, this is probably a wrong decision. But the answer's no. Have a nice day. There's, yeah. I don't want to segue, from the, the crux of the podcast. But there's something there, right? As a coach, I want to, go and say, Have you coached that guy? I had almost that exact situation at a workplace one time and I had the same conversation, with someone I worked for one time and she replied back to me is, this is a great way to basically the organizational structure, but, it's, it's too radical for where we came from that the pyramid org chart and where we're going to the, the team topology style, whatever. And we're not going to do it now, not, not, not, we're never going to do it, but we're not going to do it now. That was the old product management stakeholder management of like. That's a great idea, but not now so that in my brain that translates of course to like no never yeah Yeah, no, but not now just means uh Maybe I just don't use a single word for it. Maybe if you are going to be engaging in doing agile. You've got to get enough people on side with you from leadership that are willing to give it a go. Right. I think that that's my bottom line. Well I agree and also sometimes you cannot get enough people and then you need to be emboldened enough to say okay I'm just gonna do this. That's what I was saying earlier, roll up your sleeves and say, let me just show you how it could work. Well, in, in this case where, where you've already got agreement on the alignment, Hey, should we do this thing? Yes, we should. Hey, are we going to do it? Since you agree that we should know, we're not going to do it. Okay. Well, why? Well, cause I'm afraid of X, Y, Z, like whatever. There were reasons, right? Cause I'm afraid of this. Okay, cool. Like the the follow up to that should have been okay, well, I understand we don't want to take on the entire organization, but maybe we start with a logical segment, one product and all the teams to support that product all through the entire business. I would not, I would not like knowing what I know now. Go back in time, I would not separate just the development or the development and the whatever, I mean, the, the, the, the requirements and then the development and the testing, I, I wouldn't separate that. I would say, let me run an entire business and give me access to everyone. I need to run this business and then separate it so that I can use throughput accounting all the way through from start to finish. What I mean? The finances follow the people management follows. The incentive structure follows, , and then all the work and everything that goes with it, the customers, everything that goes with it, and to see if I can get an agreement to just try it in a, like that, like what you're saying, hey, let me just try. This little pilot, but but a true end-to-end pilot. Yeah. Not just a pilot that's like, well, you, you developers go over there and you just play around. Go play the role. Play around. Yeah. No, I completely agree with that. So if you were to do that, that latter approach, which is just, just take that, just the development, right? That's not gonna get you anything because it's gonna be hard to show any impact, any value out of doing agile, being agile, et cetera. The only thing you might hope to get there, is maybe some impact around cost accounting, right? Not throughput. Throughput involves really the end to end. So take a sliver of the business, right? Just, just a small sliver end to end to your point, right? And then follow that through. And when you say you can do something and you actually do something, that's it. That's, that's really what you're looking for. So now that becomes that. You know, that lighthouse, that beacon, right? And you can now say, look, if I can do this here, what if all of us can do this? Right? What does that mean for us as an organization? At that level, you need to not engage the individual. Stakeholders alone of these other segments, you need to engage senior leadership, right? The C level folks, right? And say, look at this because they understand the financial angle of it, right? This little sliver of the business has transformed and it means X for us. So extrapolate that now, and this is what it means. If you're, if you're, willing to give us The rope to work with. Let's try this for a quarter. So this goes back to what we always talk about in the podcast. Don't go in and say we're going to be agile going forward because I've proven that it works in this little sliver because you'll find 50 people that say Yeah, that's great. It doesn't work for us because, we're special, right? So we just don't do that. We just say, let's try it. Let's try it for a month. Let's try it for a quarter, depending on your scale. So it's not like you're saying, well, shove this down your throat. We're gonna be agile. No, we're gonna try it. We'll reevaluate after that. And oh, by the way, have you got a better idea? Give me the details of a better idea and let's evaluate that. You can put the ball back in their court that way. That's a bit of a, bit of a risky play because you don't quite know what they're going to come up with. But, get their engagement that way. You got a better idea? Show me. Give me the details. I'm scared of that tactic because that's how we get... Picking and shoot, like we're going to do, we're not going to be agile, but we're all going to do daily standups and say that we're agile now. And then you have to have the guts to stand there and say, that's not going to work. That's not agile. That's agile in name only. That's right. Which is quite prevalent out there. That's just changing, changing the title on somebody's business card. Yeah. And that does run the risk of them saying, look, for 50 plus years, we've been working in this way. What makes you think we'll be successful? Because if you keep on doing what you've done, you're always going to get what you've got. You've acknowledged that you've got challenges, your competitors are moving faster, your deliveries are always falling behind schedule, you've got turnover because people aren't happy, they're leaving because they don't like the culture, you know you have a challenge, you've got to come up with a way to build a better mousetrap. That's when they say, you're absolutely right, he'll go first. Right? I'm not going to be the first one. So it takes people at risk averse. That's where I'm getting. And it takes courage. It does take courage. It takes courage. And that's why I'm saying show by example that it works. But then also don't say just because it's worked in your little microcosm, it's going to work for the bigger, the bigger whole, right? I think from an operational standpoint, I would say if you're taking a sliver of the business to kind of pilot this and showcase that it works, right. Why stop at your work? Why not bring the customer in and have them say, how did this new way of working work for you? As a customer, did you see anything different? How would you feel if we continued in this way across all the domains of the business, rather than just. This one aspect. So when you phone in for a complaint, right, you're speaking with another, I'll call it department because that's often what they are. Customer support. Let's say that's not us. We're, let's say we're, we're developers or we do development, but we don't support them. We, that's somebody else. What if this same approach that we took for development was used by our support people, by our contract people that you sign up support contracts with? Would that be a better experience for you? And if they come into the fold, now you can link arms with them and say, Look, people that are paying us agree that this new way is better for them, right? Where it gets challenging though, so I think this is a good starting point, right? So people who are wondering how you can start that, You might consider that, but I'll warn you this, this, this is kind of like headwinds coming at you. If you get to this point, people will say, prove it. That's easily, that's the easy ask. Prove it, right? And then it's not a, it's not an easy thing to furnish. Well, just prove it that it's better for them. You know, well, these customers say that. Yeah, they're always, proponents anyway. And they're always going to say yes, because they've been with us for 30 years. They're not going anywhere. What about these new people? So you're going to have all these road bumps, right? What you have to do is to say, going back to what you were saying, William, right? Your way, you wouldn't say it like this, but the old way, the way we're currently working in those other domains is not having the impact that we desire. So clearly we have to change. And at that point you could say this is one such change. Let's just try it for... A month. Let's try it and see what happens. Or such other amount of time as is reasonably necessary to generate the proof. Indeed. Indeed. It's just contextual. Absolutely. Yeah. Now I can, I can hear my, my friends at Boeing saying, what do you mean a month? Does this approach change depending on the size of the company? Is it easier in smaller companies than bigger companies or vice versa? What do you think? I think it is just because you have fewer number of people that you have to, try and convince. The mountain in front of you is a hill instead of a mountain. It's easier to go over it, right? Then worrying about if there is there another summit. I've just thought I've reached a summit. I thought that was it. You look up And you say, oh, goodness, there's another summit. I felt like that when I, when I met Nevis. It was like that. It's like, this is not the summit. The other summit is up there. And you get up there and go, oh, there's more. Right? In larger organizations, you have people that are entrenched in their interests. Right? And they will really fight you tooth and nail. In smaller ones, they might. But, you have easier access to them, you have easier access to the people that can override that, perhaps. So I think in a way, it is easier, you know. Yeah, I was gonna agree from the perspective of, I think larger organizations will probably have a higher likelihood of having terrible org design that is sabotaging their ability to change. And that has nothing to do with being agile. I'm just talking about their ability to change. Period. you can also interpret that as ability to react to the market. Google has now entered your market segment. What are you going to do? Well, we're going to keep doing the things that we're doing and everything's going to be... That's probably not a good response to Google entering your market segment. You probably should do something. And, and if you're just unable to do anything... Because, things have dragged along, and it takes six months to even change direction, that's just not acceptable. I think I got this out of the the second Deming book. He had a... I might, I might be completely spacing this one, but... He has a graphic about, effort in, and then a black box, and then the results out. But then the environment is pressing against the black box, and the environment changes. And if you're not watching what's happening in the environment, you're not aware that the environment is changing around your black box. So you're expecting, you're giving it the same inputs, you're expecting the same outputs, and then you're seeing your outputs diminish, or your outputs come out differently or whatever, and you don't understand because you're like, I didn't change anything inside the black box. You know, yeah, but you, you've ignored the environment that you're in. Yeah, I think you've nailed it. So, the black box approach, classic, right? I mean, you've got that whole, control feedback, right? That, so it, it's, it's one thing to have that negative feedback loop where you can actually improve things. And it's a fine line to it becoming a positive feedback loop where it just simply builds on itself and just goes spiraling into oblivion. The whole, the whole point you were making there, at that time I was thinking about companies that, there's so many of them. Sears, Kmart, I mean, you name it, Blockbuster, all these companies that said, yeah, it's new stuff, right? The Googles of the world, the new dot com stuff. We've been doing this for... Over a hundred years, said the, someone quite important at Sears Roebuck, I'm sure at some point, but they ignored the fact that the customer experience was so much better with these other competitors. But these people are like, well, what's Sears? People are always going to come at our doors and they didn't. Yeah, the funny thing is this is not something. That I gained from my time, in agile coaching, like being a scrum master, being an agile coach. I did not gain these skills. I gained these skills from product management. Understanding we should be constantly doing market analysis in both our market and adjacent markets. We also should be like sales and marketing both should have boards that I can go look at or backlog Whatever you want to translate to basically sales and marketing both should have What have you tried in this market? What, what, what, what positioning is resonating? With these different personas and what is not? And, I need to know that because when I'm building products, why would I build a product that's no longer resonating? Or why would I enhance a product? You know, if you're looking at the, the product life cycle, the product life cycle where, it has like a it's growing and then it's stable and then you start winding it down and whatever. If the market's winding down, should my product not also be winding down? Why should I be throwing more and more and more money into a diminishing, diminishing market? Because sales tells you, right? So yeah, I absolutely agree that they, if they don't have that, that whole experimentation mindset, they'll say, we need to keep investing in this product. Well, how do you know there's a demand for it? Well, trust me, there is. Well, if you're working at a feature factory, you've always taken your orders from sales. They tell you what they're doing. You know, Oh, we could, this client told us if we just add two more widgets, in our app, they would have signed with us. So you need to add those two widgets for this client that we didn't get in the pipeline. Like, wait a minute, I don't need to do that. You, we, we repassed on the, you know what I mean? Why would I do that? So bringing this back to what do you do now you've decided to go agile. It just shows how you've got to keep all the different departments of an enterprise on side so that sales aren't selling past the specifications of the product line, or they're not selling in excessive quantity beyond your ability to service. And so this whole collaboration mindset needs to be instilled in the enterprise, particularly leadership right at the very beginning. Otherwise you're setting yourself up for failure. And one of the things I want to talk about for a minute, pursuant to all of that, is this. Are the right people going to be available to you to give input and to talk to, and give ideas, and create feedback for you. I don't know what your experience is, fellas, but I would say at least half of the time, I ask those specific questions up front, and I get that, Oh yeah, we're on side with you, we'll be there for you, William. Look, there's, nothing's more important than this. We know we need to change. And over time, that commitment, even if it was honestly given up front, diminishes, doesn't it, guys? It plummets. It doesn't just diminish, mate. It actually plummets, I found. Because they're just there, look, they're just there paying lip service. Because their boss is in the room, quite frankly, right? So that's what they say. Yes. Yes. We're right behind you. And then, right. As soon as that, that meeting's over, they're like, okay. Yeah. You know? If you're sticking with your terrible org design. I'm right there with you. However, like the, the better organization is one where you've broken out these functions in the team. So you don't need to go and get 30 people in a room to make a decision. You just got to get a, a, a cross team sliver of all the different teams it takes to implement something even if your product was like a, like the Microsoft office suite and you had to go get a different product manager for, each of the different, you had to get your. Does OneNote even, is that a real application? Yeah, it's still an app. You gotta go get your Outlook guy and your Excel guy. I'm assuming they're not women. You gotta go get your Outlook woman and your Excel woman and your Word person. Yeah, sure. as opposed to if I don't change my terrible org design and now I've gotta get, I've got to get the person who makes decisions for Word and their boss and then maybe the department boss over that who's supervises both of them but then whoever's making the change sending it from this other application I get their, their boss and I get the okay to send data from this system to that system and then it's managed by some other platform team so I got to get them on the line And open a ticket to get access like, so if you can get them all together, now you've got, now you've got 50 people sat on a team's call or something, most of whom are either falling asleep or checking their bank balance or emailing somebody and, they're not engaged and they're not relevant. That's that's like, there are some of this, again, this is why I got out of this career field because like, there's some of these that, that you will not be successful. When these factors are working against you if the org is not designed For any kind of success with agility like you I mean, I guess you could try to reform the whole if you're if you're positioned High enough with the right people in you know Or if you're in a small company and you have direct access to the c suite then maybe you can make this difference. Like I, but I don't like a lot of what I've experience is you're not there. You're stuck in the mud trying to make these improvements. And it's like, I mean, they might, they may stay improved even if you're really good and really effective as long as you are there. And as long as that person in the leadership is there, but the minute that either you go away or the lead or the person in leadership goes away, all your work goes away. And like that, I just can't, I am not okay with that I want to take a contrarian position a little bit, it's very satisfying when you're able to. Overcome a hurdle and make a change in the team that makes a difference to the organization. If you can get these little wins, and sometimes they are only little wins, it's really very rewarding. So don't think, because I think we've had a bit of a negative tone to this conversation if I'm honest. Don't think it's all doom and gloom. Yeah, be real, know that the doom and gloom is out there. But also know that when you make a change and it makes the world either less stressful for the team, or you see the velocity go up and you see productivity go up, and you do see more coming out of that black box on the right hand side, it, it's very satisfying and it's very rewarding. And sooner or later, people are going to take note. And they're going to say, hey, wow, good, this is good now. I, I like this. I, I'm on side with it. Let's go. What else can we do?'cause success breeds success. Yeah. Bingo. Absolutely. So, so, so I wanted to just inject that fellas to bring some balance to the dialogue. Yeah, no, I'm glad you did that because really all we do, we're not saying that this is all just, we're just gonna jump off a, full off a cliff. We're just pointing out to our viewership. Both of, both of them. Listenership. Both of them, yeah. Those of you that are on their, on their treadmills listening to us, those people too. Yeah. That we're pointing out some of these. Potholes on your progress right along your way, you're going to find these. So if you know they're there. That's our hope, that you can at least see them coming at you, and you can circumvent around them. have you ever had to advise? A business that something like this on current course and speed, you can't get there from here. Have you guys had that conversation ever with? Absolutely. Yeah, we know for sure. Yeah. I'm not going to say it was productive, but I certainly have, but at least it plants in the mind of, other people that something significant needs to change. For me personally, it's gone one of two different ways, right? Yeah, it wasn't productive. They said, thanks for coming. I was just about to say, I know one of the ways you're going. Yeah, now that's. You know, the one, one of the ways I'm going is, we believe you and, we know that. But this failure is tied to you. So if we just get rid of you and get a new you, maybe we'll get a different message. That's right. Exactly. Yeah, the odd times when I've had a slightly different outcome out of those discussions It's been similar to what you were saying earlier. Thank you. This is very enlightening, right? You're absolutely correct We will change just not now. So then that's when you just say Because if it's just not now what I'm hearing what they're saying is just not now What I'm hearing is, thanks for coming. Don't let the door hit you on the way out. Be sure to send a follow up email memorializing the decision making process. It won't matter. Because they've already made that decision in their minds. So, that, that's really how it's gone. I really long for the day when they say, You're right, there is, we're heading over the waterfall. We can see the edge. Thanks for pointing that out. What do we need to do to change? I'm gonna say take those oarsmen that are at the back of the canoe, not at the front. And get them to go the opposite way. And now, take the ones that are in the front, and get them to go the opposite way, and we have a chance to turn this thing around, at least go sideways, and then hopefully we can get on shore. Yeah, you have to go in there with an action plan, a remedial action plan, that shows what the challenges are right now. Why, why we've, why we are failing in the current approach and what the, what the brave new world looks like, the remediated approach is that like, Oh, here, here's a good one. Here's a good, pushback for, for y'all. Is it okay to go in with an action plan as an agile coach? Cause I feel like the typical agile coach will say. I'm just going to meet you where you are and everything's fine. Oh, look, I want to, I want to buy my book. No, I want to dig into it. I want to dig into it. But I want to finish the, the thought I had when you said go in with an action plan. It's so tactically speaking, you go in with an action plan. My advice to those of you that are. thinking about doing this is going with two going with an action plan that you know is absolutely unrealistic, ridiculous, whatever, propose that so they will knock it down. We've said this on the podcast. I've said it before, prop it up so they can knock it down. That's what this is, right? So you're going to say something that is completely ridiculous, and they'll say, that'll never work. And you go, okay, how about this? And that's when your true action plan is revealed, right? I don't know why, psychologists will tell us why, I'm sure. But, and if you're a psychologist, please, let us know in the comments below, but this actually has a better chance of working. At least that's been my experience. They just say you're wrong about that first one, but this one, this might have some legs. Let's talk about that. Whereas if I had just presented option number two as my only option, it would have had the same outcome as option number one did. Nah, that'll never work here because, we're special. I already forgot what, what my challenge was. It wasn't about anything I had written down, which is the worst. Or the best, depending on how you look at it.. Oh, I know, it was, it was, you saying going in there with a plan, and, and I was saying, isn't going in there with a plan, the, the... What you're told not to do, like go in there and, every customer is a unique, special, they get a special star. And every problem is completely unique and different. Yes, yes, yes. This is the, this is the textbook coming out. I'm going to tell you what's real guys. And it's this every organization and every team has a different level of maturity to it. And the stuff you read about in textbooks works just fine. If your organization is mature in its thinking, particularly it's agile thinking, and if your teams are mature, sophisticated, cross functional, agile teams in that environment, then yes, you can coach coach. As their level of maturity and sophistication diminishes, I have found that I have to. step a little bit away from coaching and start leading. Because they don't know what they don't know. So where that tipping point is, you have to kind of feel your way forward a bit. And you have to sense when it's a good time just to coach. Also, when you need to plug the gap, if that's the right metaphor, and go into a little bit of leadership teaching to put them on the right track again. As I said, because they don't know what they don't know. And there's always some bright spark with a brainwave that could derail everything. The loudest voice in the room syndrome. So, that's again where you have to step up. You have to have the confidence. You have to have the knowledge base, the chops to know what you're talking about, and you have to, you have to teach and lead. So it's on a spectrum and it's up to you to figure out how to move up and down that spectrum. So that's my rebuttal to that proposition. Yeah, I mean, yeah, but you, like you threw out a whole bunch of new ideas that I want to keep going on , but also like a whole bunch of new ideas, which is, You, you go in there with a plan, but, but, either, I don't remember which one of you exactly said, go in there with a, like a vision for their organizational transformation. Let's pretend that I'm coming in on contract for a second. I'm coming in this contract. I'm going to be your agile coach. I'm your partner. this is what your organization looks like. Now I've, I've gone through, I've interviewed people. I've taught, I've had one on ones. You know, I met with all the different departments, all different leads, all up and down the pyramid. I'm assuming they're, they're, they have a pyramid. Most do. Pyramid structure. And this is what your organization will look like 18 months from now, I've done at that point what adjunct coaches say like, Oh no, you should never do that. How could you? Possibly. I'm like, yeah, but you got like part of leadership is leading them towards a vision. If you don't outline something, what you're going to get is every single manager's vision of their, how the organization can be kind of crowbar to service their little department. And then they're going to push forward with as much political capital as they can. But the point is, like my point before. My negative Nancy point before was it seems contrary to everything I have been taught. I guess been taught, been exposed to in my career of like, no, no, no, don't go in there and outline a plan for them because then if it all falls apart, it's your specifically your fault because they never took ownership of any of the work. Which is a very good point. I mean, it's, it's very, there's plenty of ways to mitigate risk liability. So I, I'm never scared about that. Because if I see, if I see an enterprise or a team doesn't know what they don't know, I will go in with an array of suggestions to start them thinking about how to plug those gaps. And that may not suit the traditional mold of what an agile coach shouldn't do. I've crossed a, I've crossed a line, a tipping point, haven't I, there? But I want to see them succeed. I can see from afar, as a dispassionate consultant, what they're missing. So I feel I'm remiss if I don't give them some ideas to noodle on. About what best practices going forward might be. I'll throw a contentious one out to get into straight away. Cause I'll partner with whatever engineering leader or whatever. And I'll say, Hey, I've noticed, your developers don't like, they do like a formal code review at the end of a work item or whatever, but they don't peer while the work is going on. And like, you, you wouldn't have to go through all this code review stuff if you just had people peer the entire time. Have you thought about that? What, why do you have a reason for not doing that? Or, what, what's, what's going on here? Well, so the more, the more I talk, the more accusatory it sounds. Yeah. Then I, I get where you come from. So typically the comeback is, it'll be like, what do you know, kid! Get out of here! And also the fact that they'll say, well, on our team, we have these developers and we have a tech lead, so the tech lead has to basically, review every PR and approve everything. As soon as I hear that, I'm thinking, okay, we have a stage gate here, right? This is not a cross functional team at that point, because there's a fear of trusting your team, right? So that's what you focus on at that point. But going back to what you were saying earlier, I thought immediately about the festival metaphor. You go in there and you're on the carousel, so that's all you care about is going around on a horizontal surface, but you're going around in circles. Granted, the horses might be going up and down, but you're still on the ground. Or, you're on the ferris wheel. definitely off the ground. You want to get back on the ground. You hope you do. Right? So it's like, it's what matters to you at that point in time. Know where you need to be. If you don't know where you need to be, you'll get somewhere, it may not be where you actually have to be, but you'll get somewhere. And this is why they pay us the medium bucks. Oh wait, this? Yeah! I thought it was a labor of love! Feels like it sometimes. It does, it certainly does. So, all right, so I think we, we kind of need a, need a wrap up here, right? Paying you guys? There's a meme for that, I think. There is a meme for that. If, if you're still with us, the two of you, thank you, first of all, for, staying with us through the end. And do let us know, what your thoughts are in the comments below. And, subscribe and like that. button down below. Be courageous. Indeed.