AA93 - Being a Positive Advocate for Agile

So let's have a session about advocating agile on arguing agile. What is being a good advocate? For Agile look like? And what does it mean to you? It, to me, it means looking at ways of working, forget the, a word for a minute, right? looking at ways of working a word that they, the agile word, the agile word got lead a, a word drawn around here. Lots of, lots of a words. Just say how people are working in a complex. If you don't have a complex environment where there are multiple factors that would, that would be at play for you to achieve an outcome. You don't have to be agile, you can forecast things and you could pretty much track close to the forecast because things are fairly cut and dry and not complex, not unpredictable, but for the most part, most work is complex these days and not just software development. So forecasting ahead of time, many months ahead, that really hasn't born fruit over the years. So really what we're saying is why don't we pivot from that old way of working learn just enough and then project out a little more, try a few things out, learn just enough and keep doing that. That's agile. So that's the way we're advocating agile is not just software development, but. Okay. Just do enough planning. Sure. And then try things out. Yeah. What do you think? I think that to advocate for agile, it almost inherently leads you to some extent and this may be a strong word to use for instance, in an organization, but to argue agile or certainly to defend it, explain it you need to be able to define, what problems are we trying to solve? Right. Are we doing them already in an efficient way? Are we meeting our needs? Are we meeting our budget? Are we getting things out appropriately on time and with great quality to our customers using whatever methods we're using. If the answer is yes to that, well, then we don't. Need to argue or advocate for anything, but what we find oftentimes most times, particularly in software, but now we're finding in far many more industries, is that the traditional way of doing things where we're thinking we need to do these long term plans, very segregated, siloed, lots of handoffs dependencies. And we're saying, you know what? This isn't efficient. It, it is less than effective. It's costing us a lot of money. And at the end of the, at the end of it, we are really not getting a quality product or one that our customers are satisfied with. And if any of those things are true for you, then it's time to start advocating for agile. So there was a podcast we did a long, long time ago where we said, , speed and effectiveness may not be what your company's going for. Let's say you join a company as a scrum master only because that's the easiest example that, that I could give here. You join a company and maybe you have some Scrum certifications and experience, and nobody else in the org has any experience or came from companies that practice Agile now. Wouldn't you be the default advocate in situations like that where the situation where you've been trained, wouldn't it be up to you to do things like build consensus and raise awareness, cheerlead? all of the above really If the organization is already delivering well to their strategic objectives, then great. Right. You don't have a problem what's worth solving here, but, but if they're not, then you could look at that and say, how can we how can we influence the process to attain a, a more optimal outcome? And you start peeling away at the existing processes. And you're finding, you'll probably find I would posit that you are peeling away pieces of the current process that are largely waterfall type oriented, where we are doing lots of activity, a hand off to B hand off to C, et cetera. I agree, but only in a case where they, they are satisfied with the way that things are. I think of the companies that I've been at, where management lets it be known that if every person on the team's not a hundred percent utilize, They, they meaning the company is somehow being cheated out of money. So management spends a considerable,, amount of time and effort making themselves confident that everyone has enough work, and as soon as the person is done with the work, they're handed the next work item, and then nobody ever has idle time and the assembly line is efficient as possible. So make, making the most effective product and making an impact to customers, that's not what management's focus is I'm trying to illustrate that the things that management is measuring,, they're spending less time focusing on whether the customer is happy and more time, making sure to squeeze their developers to make sure they aren't, , , secretly working 39.5 hours rather than 40 hours or whatever I think the part of the difficulty is there's a perceived sense of control in that environment that they're seeking. Right. So when they say, well, we have to justify a headcount of X, then, then they have to justify that. Right. And so they say, well, we're keeping people busy, we've got an average utilization of 75%. Right. And the question is, why isn't it? 85%. So so then yes, down comes the pressure to do more and more and more. But make busy work, it, it's not it's output is what they're looking for here. I was once in a position where a, a change to the culture. It all came from one discussion between,, a senior manager in that organization or like a director in that organization and, a C-level executive and the. The conversation went like this. The senior manager says, Hey, my department's doing great. We're all on track with our forecast according to our normal capacity and whatnot. And the C level, I think this was a cfo. He says, okay, well what's your normal capacity per employee? And the senior manager said, well, we plan for a utilization during our sprints for 6.5 hours. Per day per developer. And of course the CFO was like 6.5 hours. I'm like, there's eight hours in a day. Why only 6.5? Why not 7.5? Because you know's some things come up and people gotta get up in their seat. 7.5 sounds good. Right? And the senior manager completely folded and said, yes, sir, whatever you say. And, , that, that, that basically is the story of how that, , shop went from like sustainable development to like grindhouse development basically overnight. Because the, if the, because the manager. Story, if we're gonna take this back to agile principles, like he, he or she could have been anyone, , did not have the courage to stand up, , and, and basically fold it immediately when they were challenged. So, th this, the person in this real example, didn't have the courage to raise and question leadership, , in the, in the conversation when it mattered, but the VPs feel like, okay, look, look what I've just done. I've increased efficiency by 10%. Right. And that's the message up on high. This is why we're talking about this topic. I know we're starting, I know we're kind of starting this conversation at a low point where you're with a company that says, why should we be agile? Everything's working fine. But that's what a lot of companies start though. Right. We've done at home. I know, but that's so yeah, to that point, that's where a lot of companies start. Why do we want change? We're doing fine. Right. And before you know, it they're in that same graveyard as Kamart and Sears. Yeah. And then before you know it, you're blockbuster yeah. That's right. Exactly. Yeah. I have a couple of points. I learned this actually in nursing school and, and it's, it's funny. The alignment that I see across different methodologies, regardless of industry inside or outside of agile software development makes no difference that I see the scientific method just being reexplained or redefined or renamed over and over and over again. So in nursing, we had our, our nursing process. Where we would evaluate the patient, make some kind of a diagnosis. Then we would do some kind of a treatment or an intervention of some type. And then we would reevaluate sound familiar spec to that. Okay. Say, Hey, I mean, and, but we see that, oh, that's the, that's the scientific process. It literally is. And that's what agile is. I mean, like that's, it's literally is the same thing, but we see this in so many different so many different types of work and, and things in general in life, we would be see this when we're making food, when making a recipe, right. I like where you're going and I don't want to interrupt your flow., but I have to because I have a funny allegory, , to what you're bringing up., What I'm used to seeing in software I guess is the equivalent of a random doctor rolling in and saying, oh, no, I know what the problem is. It's this, , and I, like, you watch. And they don't look at any charts and they don't look at any data., , they don't, they don't look for any evidence or whatever. And this, like I bring up because it brings me back to one of my, , uh,, seminal opinions, , , why I prefer being in product. So in product, , since you have the ear of the., you're sort of, , a little bit insulated, and you can actually ask that question. What makes you think, , x, y, z without the fear of reprisal? I can't even begin to guess the percentage of cultures out there where this kind of thing is okay. Versus all the companies that randomly questioning your boss or a VP or someone in, , a VP of sales or whatever. Like, it just won't fly in the culture. actually, now I think about it, I've been in companies where it doesn't even fly as a product person come and think of it, but it's less likely that that will be the case. what I have found is as long as you've built a good supporting organization around you, , that really understands and believes in Agile's principles and values, you can lead the culture in, anybody should be able to question anything, and that's okay., and I almost don't want to ask this cuz it's a loaded question, but like, in in a culture that sees that question as a challenge, if you're being an advocate for agile, like is there a way that you can soften that blow before you asked that question? So you kind of not looked at that way. I think we have so this is maybe a good segue. We do have something else on our list of topics today. If you are empowered to say that, or if you're in an environment where you feel empowered to say that maybe there's a better way, or can we question how well we're really doing? Yeah. Right. Then you'll basically have a sense of safety, that you can say that without getting fired or or being told, stay in your lane. Right. This is not, you just knuckle down, do your job. Yeah. So if, if an organization isn't open to listening to people about those things about anything, right. How did they get better? I mean, it's, it's just a top down decision at that point I know best you're gonna do what I'm saying. And then you'll. People at the next tier, I'll put it that way. They will emulate you. Mm-hmm as a leader and they'll do the same thing to their people. Right. They'll just say, do as I say. So that's that then snowballs into this culture of no risk taking, right. Just, just follow the order. Everybody's in order taker now. let's shuffle this under the arguing agile banner, and let's argue about this. So, so sure. Like the arguing point here is like anybody in the culture could do that. It doesn't necessarily have to be a manager or whatever. Like you could have a developer, your team who shuts down conversation about whatever, because they have a specific way they want to overbearing personalities or whatever. If you're gonna advocate for agile in your environment, this is sort of why I bring up it it's a, this is, it's not even related as a topic, so I hate to even bring it up here. But when I throw out I think the scrum masters should work under the banner of HR. When I throw that. As a, like a kind of a challenge. Sometimes when I throw that out and people are like, HR has no idea what ScrumMasters do or what agile coaches do. Why, why would, why would you place in there? I'm like HR has no idea what anyone does. Why like, where are we going? Everybody's just selling a spreadsheet as far. Exactly. So, I mean but, If they were under hr, maybe they would be better positioned to have more influence in the culture to say, , Hey, we have these people in our culture and they're never wrong basically identifying people that are stuck in a fixed mindset in the organization. They can question the status quo and yeah, So for people whose companies are., these type of people. I guess someone could stick it out and try to change people one by one and do that heavy lifting. But the more likely scenario, I think is they're just going to go look for a different job yeah. There's a lot there. I mean, listen to how they're just, just examine how they're rewarded. What's the reward structure based on, right. It's not based on improving others. It's based on getting ahead as an individual. so right there, you could question, how is that possible to instill a culture of inclusion and people coming in and contributing to this mindset of questioning everything? It's ironic because senior leadership will say things like we're embracing agility, right. And it'll be in your company reports and, and financial reports and whatever else, that's one thing. But when you look at how they're really acting behaving every day, it's completely different. Yeah. That's what I've seen anyway. So just speak to your comment in regards to HR. That could work. However, if you have a company that falls under this command and control type of culture, in my experience, HR is gonna fall under that cultural oh yeah. Kind of umbrella just as any other. Oh yeah. Any other piece of the organization, which means that just moving, for instance, a scrum master or, or change agent in regards to advocating for agile, into HR may not be impactful. Mm-hmm some of the other things that I, that I just kind of thought about was so certainly organizational culture. I mean, I think that is the, the underpinning of. Creating the I know I used the term psychological safety, but creating the trust comfort and psychological safety of any employee to be able to stand up and say, you know what? I have a great idea, or what this isn't working, or I don't really agree with that. And this is why, and that doesn't necessarily mean that, Hey, that their idea or thoughts are would be adopted or even appropriate, but the fact that they are comfortable to do that. Yeah. Should culture is gonna be the overarching feature, which would even open that possibility, but there's some other things. So their level of experience and confidence so somebody who's going, like I'm kind of new at this. I don't really feel confident. I think maybe this might be something I should bring up, but I'm probably wrong because I just I'm, I'm not that schooled in this and I'm, I'm still learning. So in that regard, being supported by. Colleagues people in your, at your level, people of your own that, that you do feel comfortable with typically, maybe being more candid with and could help you mm-hmm right. So that is also cultural. But it's, it's a different way of approaching and can kind of overcome some of those things that are maybe personality based or, or, or, or lack of confidence. And and then the, to your, to your point in regards to the organizational or the, are they working their talk? Are they getting up there? Are they showing. Command and control type of behavior, or are they appreciating and saying, you know what, I haven't, that, that's a really great point. I really appreciate you bringing that up. I hadn't thought of it in that way. Yeah. Right. So encouraging that in a way that would encourage them employees. So are they walking that talk or are they being that highest paid person in the room who says, this is the way it's going to be? Or this is, these are my thoughts and it shuts down the conversation completely and any, in any ingenuity and innovation. Right. So again, back to cultural, and then the other thing I'll just back up on is, is I think you hit on a huge point and a lot of times we're talking about motive. So usually we're trying to kind of understand what's the motive in pushing this. So from 75 to 85%, incentives. What are the incentives for that who's being incentivized, it usually is not the people that are being pushed from 75 to 80, 85%. Right. So, so figuring that out and also being brave enough or comfortable enough, or I, I, I mean, some other adjective enough to be able to come to that person and say what are your real motivations? And are they the are, are they the, are we looking, being penny wise and pound foolish share, right. So that you can get your bonus, but does that help our organization over the next year or five years? Right. And my last point I would make is moving that needle from 75 to 85. in my experience, you tell me to qualify my work and what I'm doing in a day to make sure that I am documenting every down to the 15 minute mark of what project I am putting these minutes into for, for every 15 minute increment and charging it to the customer. And, and if you want me to move that from 75 to 85%, you know what, the next day it's gonna happen, it'll happen. Of course. Is it fact, is it something that, I mean, it's gonna make your metrics look really good. Yeah. So those that are demanding that improvement. The metrics are judged by that that's the problem, they they're evaluated on that. Mm-hmm and so they can look upwards and go, Hey boss, look what I did. I got 'em up to 85, 10% improvement. Yay. Where's my bonus. At the team level though, it's like I'm trying to think of a good metaphor here. Maybe a chariot, where you have multiple horses pulling this chariot. Right. And, and it's moving along, but like, why is that, is it because of a given horse that's leading the others or is it, are they all pulling together? Who are you gonna reward? Who are you gonna whip? You know? So this whole model of individual based, incentives, right. That I think is an anathema to working well in a agile way. I think that needs to be team based. We've tackled this before I think on one of the other podcasts. Right. I have to say there's some hope on this front because I've seen some things in this management 3.0 type of talks, right. Where people do the 360 S and everybody evaluates everybody else and it's fully transparent, but I haven't seen that in large organizations. I've only seen it in very, very small ones. And they're pretty effective at that. Can this be scaled up? I don't know, stormy, you said something along the lines of getting people to back you up and building alliances. I have this Marty Kagan missionary's, not mercenary, stuck in my head., I think of when I was, I was deployed as an ad coach. I had to figure out who in the organization supports agility and who is on the same page, and, and leverage those relationships to help agility advance in the organization. For example, if you're a developer who likes working in an agile, agile way, you wanna find the other developers who wanna work the way that you wanna work because, You are the one person out from the team and the rest of your team is just like, leave me alone. I don't wanna collaborate., I just wanna put on headphones and go away. Like you're gonna have a bad time on that team. The critique in this episode is developers should be development centric., A agile should be development by developers, for developers. And , I mean, I, I, I understand why people say that., but if it was completely true wouldn't,, the developers be the number one advocates for the stuff that we're talking? For sure. Yeah. I, I think when you look at, I think it's a numbers thing. So when you look at developers, plural, there's a few developers on your team, when you look at scrum masters, one person beat the drum. So if you've got a developer who is advocating agile and other developers can possibly go along, possibly not what they need, they need some fuel to help them along. It might be this scrum master or the proton or anybody. One of the other developers to say, Hey, listen to this person. Maybe we should try it. Yeah. Let's see how it works for us. But just to go back to the question you posed, what does advocacy look like again, regardless of the role, I think there's two parts to it. One is you've gotta treat the other person as possibly not even knowing about agile ways of working. It's not that they're resistant to it. They maybe they just don't know. So there's a little bit of education, or worse, maybe they only have ever had bad experiences. Maybe you are the first person who's talked to them like an adult and not treated them like a child because they've been doing waterfall and everyone else in the community has treated them poorly. So you might be climbing an uphill. What kind of euphemism is that? I almost don't wanna leave that in cause this is so ridiculous,. You might be starting from a negative that's right. That's right. Yep. So education finding out, finding out where everybody's at first. Yeah. And then lead by example. Yes. Don't just keep talking about it, right. Lead by example, show it. Show don't tell. Yeah. Yeah. Now's the oh boy, here I go. Oh boy. Oh boy. Now's the time, the podcast where I take a minute off to say like, if, if you are the one expert in the room and you expect everyone to come to you and ask for your opinion you probably should take that responsibility seriously. You really should. I'm talking to anyone right now. Anybody, anybody. I wanted to make a quick comment. Yeah. And, and this is I in regards to, and I'm not sure if this is actually where you were going with this, but I know that originally, the agile manifesto was created by developers and for developers. Yeah. And that was very clear in the language that was used and the people that were included to create that. I think it's always, it's also been from my perspective and discussions there's been some real Some very purposeful changes throughout the years. And particularly now to the most current agile manifesto in 20, or excuse me, scrum, scrum guide, sorry, in 2020 that has move that needle to be far more inclusive of other work types. where they've removed or changed a lot of the language to be more inclusive because we've seen the value that this can bring beyond just software development. I think that by developers for developers is something that, that I don't disagree was the initial intent. But over the, years now really has adopted and changed as technology has changed as organizations has changed as organization relationships and where we're seeing organizations kind of embracing The opportunities for a less command and control structure and finding that, you know what? We have great opportunities. If we actually listen to people who are working with the applications that, or, or with the product that we're actually developing, these are the people closest to the problems, the issues, the goals, and this is where we need to, to, to kind of concentrate. So really flattening that out that has opened that door to a lot of other opportunities outside of just software developers. I'm not sure where you're leading me with this. I'm trying to follow, but I'm not, I'm not quite sure where we're going with this. There's a flourishing community of rage-aholics on LinkedIn that are claiming that it's like, it's by developers for developers and anyone. Who's not a developer. You'll never get it. You don't understand, you know what I mean? Scrum masters that, that are not, developers are useless POS that are not, developers are useless. Like everyone should be a developer. Like there's a lot of people who are thought provokers that that, that try to sell that right. I don't put any stock into that as well. Like I, I look at them online. I'm like, yeah, you're real cute. but, were they shooting themselves in the foot when they're like, you gotta do what the developers say or else you can't be effective because immediately you take that back to industry and industry's gonna just scoff at it and she's not gonna take it serious. Like you're not gonna get your foot in the door. Cause the same thing as having the agile coach be like, you're doing it all wrong. You gotta just gotta do what I say and thinking they're gonna get traction with that. This is kind of the same thing I should stop and go pull up the tweets from Alistair. Coburn., I don't know if I'll leave this in., he, I remember he went on a 20 tweet stream where he mentioned that when they were designing the scrum master role, , it was designed off of all the most trivial things that Ken Schwaber,, he saw project manager is doing. So for example, you walk around and ask what everyone's status is and then you write it down in your little book and then you go tell management. And he thought that was what the scrum master should be designed to basically be a completely useless position. The equivalent is like if I were to design an executive position based off of what I saw executives do all day, like they would come in 20 minutes before. And maybe yell at some people and, practice, some golf swings, , in a meeting room and then go to lunch and, , never come back for the rest of the day. That would be the, the executives business role. But what I'm questioning is whether they undermined their own cause by doing that,, let's see if I can find the tweets. Otherwise, I can't keep this whole section in the podcast. Okay, here's the first tweet., and I'll read it for everyone listening on the audio, , podcast. So, possibly the most important thing to think about when looking at Scrum XP and quote Agile now is that as they started, they were very anti management. this part of what we're talking about with this topic, you, you can't be a good. If you're going around the organization saying everything you're doing is dumb, everything he's doing is wrong. I do like these writing, this tweet in response to people saying, scrum, , slash agile is, , a management means of, , co-opting or controlling or oppressing people., I, I do enjoy that, , cuz I see that on LinkedIn., which is funny cuz , he wrote this in whatever, mid 2021. So , , thought provokers. Anyway, he said, I'll continue. He says, , Ken Schwaber wasn't shy, that his goal was to get rid of project managers. He wanted to throw them out out of the window as a profession basically. So Scrum was not invented to help. Or PMs? PMs, , here, meaning project managers, not product managers. Okay, so buckle up cuz he continues the original xp. Replaced the PM with a junior level tracker person who went around every day and asked people how far they were. That being the perception of what the PMs did with the time. W which I have to say like he's pretty spot on., that is what a lot of low quality PMs I've worked with, , that, that deflect risk all day. That's what they do. What are you doing all day? And if you have problems, , g don't talk to me.. Oh boy. All right. He continues., scrum Masters were given zero power and zero votes on all issues. He also says the job of the scrum master was to run around the org, getting things signed, keeping people away from the team and whatever was needed so people could get work. So knowing this, , do you think they did some damage, , designing the position in this way with these restrictions? okay, let's continue., scrum struck a magnificent bargain in hostile territory management got 12 times per year, once per month to change direction in any way they wanted. The team got one month of quiet time with no interrupt., which, , I think I mentioned earlier, , about not wanting to collaborate headphones on. Go back to my dark hole. You, , you don't see anything until all the work is done. Anyway, n no execs ever got a better deal, , from here on E continues,, talking about commitments and, and why they're bad and other stuff like that. So from what he's saying here, in, in the, late nineties, early two thousands but now we're at a point where management, like management are the people laying down the rules for Scrum and Agile and whate whatever else is used at the company. So now what do we do now? It is not so for product, product in this space. So, , I'd also like to point out that Alistair is a, is he's a great follow on Twitter. He is very enlightening as well. To get here, I had to read through a years worth of tweet. So very interesting., plus he, he posts a lot of like , literature and research and stuff like that. That's very interesting to read. I'm amazed how much he tweets. So like, he must not be using the app to do it because the interface is so clunky. he's probably just looking at some of the, the sentences I think is using a voice recognition thing to tweet dictating in basically. I should just go peel back to like tweet number. Four or five or six or whatever that 22 is important. Now read that Scrum was invented to function in hostile environments. It's a really interesting contract between hard pushing execs and devs needing time to think. Okay, That's it. Okay. So where were we? I brought that up to say don't you think that that attitude is a little shortsighted because if you're designing your framework and you're trying to operate in a hostile environment, how much free rope are you gonna get when you're specifically going against the current culture and saying like, we don't need project managers, we're gonna cut them out. Right. They don't usually cut them out. They just rename them. Well, they rename them and they also scaled their role down a lot. I, I just see them renamed them and it's just the same job with no explanation and, and no training whatsoever. Well that, I, I don't think that's true though, because a typical project manager, like all the tweets, I just read everything. Everything. He just explained, I was gonna say, went on a tirade about everything he just explained in those tweets. I think it's interesting. However, none of that works when the project manager is the one funding and controlling the budget of the project., they're not gonna pay for a junior project manager to just be the go around . If they control the budget, they basically can control the process. Yeah, inevitably. So, and when they do fund somebody like that, they change the title. It's a project administrator who goes around compiling reports and sure. Asking what's the percent done today. What is it done yet? That sort of thing. So it's not a project manager cause you have to pay managers more money than an administrator. I think you're talking about actually really changing someone from one role to another where my experience is like, for instance, some SAFe implementation where they just take a project manager and rename them or any kind of agile transformation and say, okay, you are a project manager. Well, now you're a scrum master. Here you go with little to no training. So that's what I'm saying. And, and someone left to figure out, well, how do I do, yeah, I have seen that. I have seen that to your point quite often, actually often. Right. And even, even with a two day class, when they come out, it's they don't have the mindset change. They're still a project manager, just with two days of training, they just have more, more agile project manager. Exactly. Right. So what they do is they stick the word agile to your point in front. So now they're an agile project manager, but they're still project managers saying , Hey, you can't deploy scrum unless X, Y, Z, like that, that kind of like holding hostage or whatever like that. You okay. Well then we're not deploying scrum that like, I think like a hundred percent of the organizations I've ever been in like that would be the response, like mm-hmm okay. Then we're not gonna do it. We'll do something that we we'll do kanban badly. Oh yeah. The other thing they do is we say, well, we like the boards cuz they're visual. Yeah, we don't wanna do scrum. So we'll do this thing called scrum ban and will bastardize both. Right. And we'll just say, we'll hide behind this facade of agile. We make it work for us. Right. We make it work for us. We're gonna keep changing the rules because that's what we feel like doing. And that's what agile is. Right. Mm-hmm well, let let me let me take a, let me take a role that I I don't know if I really necessarily like playing on the podcast, like how, how do we get past that? You have a strong personality, right. And someone who, who has influence, right. This is not some random person on the internet. Like shouting into the void. This is someone who's, the voice carries some weight. Like, I mean, some weight, maybe not. Like if, if they're, if they have this attitude, like there's probably other people with this attitude how can I temper that to bring the message to my organization, to, to make. To make advocates out of my leadership team or out of the key managers or out of people that I need to be online with what I wanna do for the transformation. How can I do that? At the same time that these personalities are out there, I think the first thing is don't be dogmatic, be pragmatic. Don't go in there and say, we're gonna implement scrum. And here are all the things that scrum is all about. Look at that and say, how about we try these practices? Don't use the word agile, if you don't if you think, feel like they're going to resist that mm-hmm , then don't use it. Right. So tailor the delivery to what's palatable initially, at least, and over time you can introduce more and more concepts and say what we've been practicing all along here, while we're still in the shoe of the shoe hire that, that is we're on the journey. We're now moving toward. Greater and greater and greater agility. Yeah. Over time. Those people that are rather dogmatic, they go in there and say, here it is. And by the way, this is called agile. And they go, this is very, very prescriptive. What you're telling me is do it this way or no way. Right. Okay. This is gonna be one of those edits where I wish I didn't jump in. Where is the dividing line between being dogmatic and having an endstate vision in mind and pushing them to the endstate vision. Because of what I think is you're trying to get leadership to I'm using leadership very loosely. You're trying to get executives to follow you in your vision of, if we do all this, this is the organization that we will look like in the future. You probably know at least at a high level, what that looks like. We're gonna have teams that are gonna be in power. We're gonna have products that gonna have product managers. They're gonna be the CEO of the product. That kind of stuff. You probably have a vision in mind. Yeah. You gotta get 'em there, but you don't wanna be dogmatic about it. But if you go about that process being like, yeah, we can do whatever works for you and all. Wait, wait, wait, wait. Those two are different things, so I'm not suggesting you, you say we'll just make up stuff or we'll go wherever. No, but at the same time, even if you have a vision in mind, if you go in day one and say, this is where we're going, this is where this is our end state. that may be too sudden for them. Sure. Right. So what I'm suggesting is, and this is probably gonna be situational. You look at that and you say, well, yeah, that is the end vision. But to get to that, what are some steps I need to take and break it down into pieces. Yeah. Right. And to use that cliche. Right. Understand that it's a journey, but get, get them to that first stop. I almost said base camp get, get 'em to base camp. Right. And then say, okay, look how far we've come, but we're not there yet. We still have to go further. Here's the next base gap. So if you just show them the summit, they're gonna get tired of it right away and go that's too far. Yeah. Right. We don't have the appetite for that or the budget for that or the political will. Right. So I'd say, that's a great question. What is the dividing line? It isn't a line. Yeah. I think it's a continuum and it's almost like a thermometer. You can check where you're at, right. Based on in person, you can see where you've come to mm-hmm and based on that, you can say, wow, my next step should be this. So we take that as a practical thing, start with a team. Yeah. Even though eventually they're gonna need scale. But start with a team, get them practicing sound, agile principles first before you scale. I mean, everybody knows that, you don't wanna scale the bad. So that's an example. So you wouldn't go and portray a vision that what you see is this massive release, train or trains. Mm-hmm right. That you'll be lost there because they're gonna say, oh, we have to staff all these roles and these high paying RTS, whatever they are. You don't wanna do that day one. That's what I would say. The first thing I think about is coordinating with the organization with management, with leadership and figuring out, Are they open to change, so if you are saying we I'm, I'm trying to figure out how to change this organization. We are gonna move towards an agile towards agile. Is this completely kind of grassroots bottom up change, or is this something understood and being asked by, asked for, by our leadership, right. Or someone in our leadership, maybe there's a CTO or maybe there's some other people of inter management and, and, and then why is it because they heard these buzzwords rate that they were at a conference and all of a sudden, yeah, we should be agile because this is the thing to do. So why. Right. But why, what problems are we trying to solve as an organization? Are you as leadership trying to solve as an organization? If you are buying into this, why. what problems are we trying to solve? Right. And so then if I can answer those two things, then I wanna get them to be on my side. Yeah. I should be able to get them to be partners with me. Mm-hmm right now I move on to the house. So how do I get them to partner with me? Well, they need data, so yeah, before we do any changes, right. What I'm going to need to do is if I've determined, okay, we have buy-in from leadership and we have a solid rationale as to why we have some problems we wanna solve, and we wanna move towards what Mo solving those problems. And we think that agile and whatever framework you choose is the way that, that, that could help us to move in that direction. So now I would start saying, okay, how could I gather, or what data could I gather? To show by comparison, by comparing information and data that we have thus far in our organization, assuming this has been something this is in Greenfield and something we have, we can pull information from, and then now let's create some hypotheses and, and create some new data based on the hypotheses that we're making. And then show the differences that we think we potentially could attain right. By implementing this. So these are all hypotheses at this point. Sure. So we have no hard data. We have input, but we don't have the output yet, but we can hypothesize that output based on potentially our organization or other organizations similarly. And then finally, and this leads into what you were saying is. Start small one team or one department. Right. And that's the way I would approach leadership saying this isn't something we can transition. And this is and this is really dependent. Maybe our whole organization is one team. I don't know. Right. Yeah. But if we assuming this is a moderate to large size organization, or, and we have multiple teams or multiple departments, I would also come to them. If I'm trying to get them to buy in and say, you know what we are going to take, we're gonna make a bet. We're gonna make a small bet. What is that small experiment that we wanna do with a team or with a department, and do that experiment and see if our hypotheses kind of bore out and give ourselves enough time to do that, thinking that we do need to go through that kind of forming storming, norming, transforming kind of thing too. So we need to allow for that. So I think those, those are the, those are my thoughts in regards to the, the entire process over obviously a period of time. Yeah. And I agree fully what you said. I think the thing to remember is that that very first you call it an experiment, which is a good way to look at it. But that very first team that you're working with in an. All eyes are on them. And so it's absolutely critical to, to nail that, mm-hmm and make it a showcase success. Otherwise you're gonna find all the naysayers will come out and say it doesn't work. Or here's a good one. Here is what I found. They say, we understand all this agile stuff that you're talking about, but it doesn't work here cuz we are unique. It doesn't work here. Right. We've tried it before a couple of years ago. So if you nail that first one, you can bring people over to your side, especially those that are sitting on the fence. Cuz you're gonna have people in your camp. You're gonna have people outside on your opposite side, basically just standing there looking sure. But if the first one is a success, then I think that is a you're on your way at that point. There's two things I wanna challenge, which is that we can't, we have to transform small cause people, I feel like people that buy the safe model. Yeah, right. Yeah. Right. Like everyone does that. Right. But the safe model represents like 30% of the scaling market. I don't even know what the scaling market means. What does that mean? Does that mean certifications is, I don't even know what that means. People, people using some kind of scaling framework means don't know. It means definitely they're the market leaders here. Yeah. They're the market leaders in scaling, obviously like aside from the fact that people that buy the framework want to just layer it over their command-and-control and, and call it, call it done mission, mission accomplished aside from that. Let's say we're in an organization with a thousand. Right. Like a, not a small organization at all. Right. Mm-hmm thousand people. I mean, can we not like bring in an army of consultants? I'll bring in 10 product managers and 10 scrum masters and have them partner with my current people to transform the organization basically overnight. Could you handle it all at once? Do you have to deal with it? In a small kind of one team at a time kind of controlled manner? That big bang type of approach, really just what that is, right. Come in, solve that problems overnight, bring in an army of people, first of all, it's that BI versus or anything, but we'll get back to that. Can you try that? You can try that, but when you've got people that are fundamentally resisting change in the organization, when you bring in a bunch of people in there, how do the existing staff perceive that? First of all right. They're gonna think, well what does this mean? Yeah. Is my job safe? So immediately people will be on the defensive and change adaptation is gonna be a big challenge in that scenario. Firstly that's what I would say, that, that. A cultural thing, culture of an organization doesn't change overnight. Mm-hmm , it takes a long time to change culture, you can influence the culture by other things like changing the structure and maybe some of the behaviors right. Of everybody really, but largely from leadership. So can you do that? I haven't seen evidence of that. I haven't seen that work. Yeah. I don't think I've even seen it tried because fundamentally the organization has to commit. They have to commit and say, we are gonna spend all these dollars. Probably a lot of dollars. Yeah. A lot to have people come in and, and immediately start showing results, which for all the reasons I've already gone on about, they're not evident very quickly. Mm-hmm so what does that mean? They'll stop writing the check and they'll say you failed. Yeah. And they'll fire the organization that's coming in to help.'em good. Yeah. Yeah. So I'll respond. And that I would say that in an organization of a thousand people we're trying to prove to management leadership, that this is a model that's going to benefit our organization. And they've partnered with, we've gotten them to agree and say, you know what? I can see where this would make sense. We've gotten with them to partner with us. But, and, and I, and I would caveat with this was saying that context has a lot to do with this. Is this a company that's getting ready to go under, unless we make some huge change and we're ready to invest. And, and so, I mean, so contextually, I think there's a lot, there's a lot to be gleaned from that as to what approach we would make and the buy-in that we have from leadership. So besides that though, big bang will I'll use that term, which is something we use a lot in, in healthcare in regards to transition. But sure. If we're doing big bang, we're, we're talking high risk and and, and high cost, mm-hmm, a lot to lose a lot to lose, even though it's with the allure of high reward. Correct? Yeah. So you're making a huge bet, which in my mind, is almost, it becomes anti agile. right. Where or, or, or anti scrum. If so, what was, was it Ken Schwaber that, that said I guarantee that we will fail within 30 days or less. That I think it was something to that effect. I don't know the exact quote, but, but basically what he was saying. And this is 20 plus years ago where we had three year long plans that were failing after we spent three years of time and money on. And that was very enticing. Right. So what I would say is we hear these terms like fail small and fail fast. And that's really where that comes from is because we were taking these enormous resources where we had time money spent and a lot of transition in the market, in the technology that was surpassing what we had planned out in the beginning. And so that would be my, that would be my argument to that is to say from an agile and a scrum perspective that we wanna take a small risk to our organization and a small risk financially, and that would be the benefit to that. Again, I'll go back to my caveat and saying, there may be some really some valid argument to saying what big, Bang's the way to go. We're just going to, we're gonna jump in and do this. It's all in because we're getting ready to lose it all. If we don't maybe The last thing on here, I don't really know where it fits when I was talking about like missionary versus mercenaries. To shortcut me to where I want to go. I want to bring in people who already agree kind of what you were saying with a management. Like manager's gonna bring in people that already agree with their style and their, the way they want do things. Like I am gonna seek. If I want to go through a transformation that's effective, I'm gonna seek to go pull in people, at least in the short term, at least you have the skills to train. Even if I don't plan to keep them, if they're consultants or whatever, I'm gonna bring them in. And then couple them with my people so that they can teach my people how to do the job that they know how to do for a period of time. I mean like any job you go to, you need training, so if you're gonna go through this transformation and you're gonna take all your, all my project managers are scrum masters to give the worst example that I possibly could give or all my. Customer service reps or whatever are product owners or all X is now Y right. They're all product owners now. Like they don't know what the job of product owner is. They don't know what advocacy is for a customer. They probably know what it is, but they haven't given labels to it. And they probably are not trained in any kind of certification or , any of that kind of stuff. So I'm gonna bring in people who have done the job before to sit with them. You're just gonna sit next to this person. And basically peer it's not peer programming. It's the product manager equivalent of peer programming, peer product manager. Yeah. Yeah, no, I think that makes sense to, to, so to trend you're a translator. Yeah. Yeah. Well, you're also a trainer. I mean, you're a yeah. Trainer, whatever you wanna call it, a mentor, whatever. But, you're helping someone to understand their the preconceptions and the biases that they bring in mm-hmm along with their collective experience in their career and helping them to figure out where that fits into their current role and also potentially learning about them over and above. What's expected of them and how those other experiences and in their career or, or other bodies of knowledge may actually help the organization overarching. And maybe bringing that back up too leadership and saying, Hey, did you know? I mean, this could be a really great opportunity for you to tap this resource. I think there that model of bringing in expertise to basically catalyze change in your organization, that works really well because it's not gonna happen if it was gonna happen internally. It would've done by now. So bring people in I, I wouldn't call it contractors, even though contractually that's what it is. But they're, they're trusted advisors at that point. Mm-hmm , especially at, at a higher level, the leadership level. Yes. Partnering with them and really steering them in the direction where they are themselves. The executives themselves are now. Focusing down in the organization saying, listen to this guy or these people or this company, and we're gonna follow what they're saying. So you're gonna get less resistance because now the leadership is directing people to go that way. Mm-hmm for a period of time and over that period of time, if you are a responsible consultant, what you would do is you would, you would enable the employees of that organization to be self running for after a while. Right. If you're not such a good consultant, you are just vested in yourself. And then when you leave the change stops, right. And that's not what you want, you want it to be sustainable and that's probably how you should be rewarded, I would say.