AA116 - Breaking Labels: The "Agile Purist" Stereotype

This week I sat through a vendor presentation and one of the things the presenter said was, well we can't all be agile purists. And I thought that was very, that was a very interesting little derogatory cutting remark on his behalf. Because the only other, other time I've ever heard that in my career was also a derogatory term that was coming from a project manager saying, oh, I've got these, all theses are trying to tell us how to run our projects, but they're all purists. They don't know how to live in the real world. That was the context of that conversation, and it's, it's such a biting remark that it just sticks out at me of like, this person's going outta their way. They're not just like throwing trash out of the window of their moving car. No. They're targeting it. Yeah. They're going out of their way to drive through my neighborhood. Yeah. To throw it on my lawn. that's the equivalent. So if, if they're labeling agileists as purists, I in turn wanna say they're probably naysayers. Probably. Yeah. Naysayers, right? These people either don't understand Agile, don't like it, never used it. Et cetera. So they're basically saying, well you're just the purist in the real world. It kind of works like this. Yeah. And I, I know we're gonna delve deeper into some of these these topics in this podcast, but oftentimes people have not really worked in an agile way. they don't understand it in, in layman's terms. They don't get it. Yeah. the great thing about that little dismissive cut is it, it, it basically doesn't try to learn anything that, that was a, that was a, the, the takeaway I got from this very large company that sells vendor tools to agile audiences or companies. So I was, it was actually a very surprising I was gonna say, why would they why would their representative make a comment like that? Well now that we've pointed it out, you might hear this comment, or some kind of derivative of agile purist. Now that we're pointing it out and making you aware. You won't be able to un unhear it. Are you an Agile purist? You may not know you are, but stay tuned through the duration of this podcast. You're gonna find out, what I think I want to do is who might you hear this from and then what, what can you do when you hear it? You know, what, what kind of strategies or tactics can you employ when you hear it? Because this, again, this is the equivalent of, of me walking in as a product manager and saying like, well, did you miss this day in MBA class when they were teaching strategy where were all the real strategists at, I mean, it's, it's such a dismissive like it won't win you any points. It's such a, such a, Poorly contrived, cutting remark that I can't, believe anyone would actually use it. Let alone in like a global presentation. Anyway, I don't know which one of these categories you wanna start with. Let's start at the top. Let's start with senior execs. Start at the top. Yeah. So the, so one, one audience you might hear this from would be senior executives and or management. I'm lumping management in with senior executives, but let's, let's go to the top before we get lost in the quagmire of middle management. Typically though, when you hear this from senior leadership, these are not middle managers, but people above them. Yeah, it's probably because, or likely because of one of two things. One is they really don't understand Agile and they're kind of nervous about it because it's all over the press they kind of feel like they can't avoid it, but here you are in their face talking about these things in agile terms. And frankly they're nervous. Well, they're, well, are they nervous or are they already skeptics because it's new. You know what I mean? That too. I mean, look, they, they didn't get there by being agile just because of the the time factors involved here. Right. They probably worked their way up the ladder. Mm-hmm. And agile wasn't a thing, so this is new to them and they kind of are, it's like a, it's like a wasp buzzing around their head. You know, it's there and it's annoying and they just wanna sweat it away so that's possibly why but at the same time, I wanna say these are people that have heard about, Agile and the good things it it can bring mm-hmm. From their CIO peers or conferences or whatever so they wanna give you some airtime, but they've already made their decision as to where they're coming from. Right. Prove it to me first. Right. Not, maybe this will work for us. Let's try it. They're not coming from that perspective, at least initially. so that, that's what I feel about senior execs you know, labeling agileists as purists. I mean, if the reason is they're just traditionalists and this is what they learned and this is what has worked for them all these years, right. In whatever market segment they're in. I could come along with that, you know? I could believe that I mean, the issue with that being the, the, the main reason is the market shifts over time and the speed at which you need to deliver to the market also increases over time. And if you're not doing anything while the market changes around you you're not, you're not a very good executive. Yeah, for sure. I mean I think, I think these people didn't get taught anything to do with Agile during their tenure. You know, if they were doing MBAs or whatever it is, it was not included. I know it wasn't in my time and I don't go back that far. Yeah. But far enough you know, the other, the other side of this I think of like managers, like middle managers or something like that. The other side of this is the pragmatist in them of, Hey, we just gotta like something came up like, throw away your sprint, or I don't care about your time box, and. Just do whatever I'm asking you to do is the top priority. You know? Cause that's, that's the pragmatic thing to do is respond to change in like your artificial time box. They view it as an artificial time box they don't really care about your rules and stuff like that. That that's, that's the, also the, the other side that a, a manager would look at this like, I agree. I, I think the managers have become managers. Managing in that way, right? Mm-hmm. So do as I say, okay, stop. Now do as I say now, right? Because that's the new priority. Mm-hmm and, and then in a way they could subvert your agile, so to speak and say, we're responding to change in this way. Right, right. I, I am telling you what the change is ,yeah. Yeah, I hadn't thought of that in our discussion, but yeah, if you, if they actually do have a little bit of knowledge on the subject they actually could do a lot of damage by using the same terms. Speaking the same language, but actually undermining the whole time because maybe they never believed in it. Maybe we were skeptical from the beginning and and they never believed in it. I mean, you get some of those smells right. So you know when that's happening, when the same managers or, or even execs for that matter are also insisting upon delivery by a certain date that they invented out of thin air, you know they're demanding Gantt charts. I mean, all of those smells. So if you get some of those, you kind of know right, where it's, where they're coming from and then when you come in and, and spout the benefits of working in an agile way and, and using the inspect and adapt, et cetera. Yeah, they're gonna label you as a purist. Yeah. Because they say, well, this is all theory, right? Yeah. I I have never done this this way and I've been successful. Yeah. Right. So you kind of have to deal with that because they're not wrong. Right. They haven't dealt with it that way. They're right in that part. And they've been successful because they are where they are. I mean you know, like I was with you right? Until the very last sentence of they're successful because they are in the position that they are, that's not necessarily true. Like sometimes a business can be successful because they happen to find themselves in a market segment that's blowing up. Or they're in a particular, like they were first to market in that, in that segment or whatever. Like they just, just showing up in the right place at the right time. Could make you successful and it might not have anything to do with good or bad management, possibly. However good management will take you much for further, but than just happens to answer a lot. Right? Yeah, yeah. Yeah. They could, they could be lucky unlikely that a a, a senior exec just got there by being lucky, like throughout their career, probably. Mm-hmm so they have a certain way of operating and that's what worked for them and has worked for them thus far. You're bringing a new paradigm. Right? And just because it's new and they, they haven't experienced it before, they're entitled to be a skeptic. I'd say. let's move over to suspect number one in the skeptic lineup, project managers. The first time I ever heard, heard and or refer was referred to as an agile purist was from a project manager who was frustrated with quote all these agile people and leadership asking for all these agile things in all these agile ways. And they just wanted the world to slow down and. Go back to the way it was with the nice Gantt charts and the not doing anything, not showing a customer for six months. And well, there's a lot of comfort in that, right? As somebody who has actually fallen foul of that, that paradigm and have recovered as a project manager, I can tell you, you create a plan and, and you float that out there and you say, this is it, thou shalt work in this way. And there's comfort in that because all you're doing after that is simply, Asking people, right. Where are we at with this? Mm-hmm. When are we gonna be done? So I can kind of see that project managers getting nervy about agile ways of working and letting teams discover things as they go along. You know, they're nervous because they can't really reliably back that date that they came up with, right. Or, or those milestones so definitely. Can understand why project managers feel this way, especially those project managers that have no introduction to Agile, right? Mm-hmm. They, they're just being told here, this is, this is where we're working now. Yeah and, and that's probably something that can be avoided, in fact, by giving them an introduction, bringing them into the world of, as opposed to just going and saying put all that aside. We're gonna work in this way suddenly I could totally see the being resistant to change from the perspective of it's not just project managers, actually product managers. I don't know if we'll get into that topic of their, I've seen a lot of product managers on LinkedIn saying like, why do I need agile? What, what, what does Agile have to do for me? Or, or, or I saw a video that I sent that was Um, introduction to Agile for product managers. Like what, what, what, what does a, which is funny cuz all these people that are complaining like that, like they're, they have the benefit of being with these Silicon Valley companies that you would, you don't need agile because their companies are organized in the most agile way any company's ever been. You know what I mean? All their teams are decentralized, broken down in a tiny and, and the funny thing is like, they can't even, they can't even understand. That they're from such a place of privilege of not having to fight the fights that all these people are fighting. I don't understand. There's no problems. Like, I don't get it. Yeah. They don't believe the mirror. I mean, you, you're right. They they're already there. Their org structures are aligned properly. Mm-hmm. The com structures are aligned properly. Right. And so they haven't seen how bad it can be. Possibly I, you know how bad it normally is, I would say Yeah. How bad it really is on the other side. Yeah, exactly. So they just say, why do we need agile? They don't realize that they already have it. Right? Yeah. Right. Yeah. That's what I mean when I say they don't believe the mirror. Yeah. Outside, outside the walls of the garden. Yeah, that's right. They've never been out there. They don't know how it is. Yeah how do you deal with that though? Like, and those people that say that how, how do you, how do you even have a conversation to say, really it is pretty bad on the other side? That's, I mean, that's a good question. Like how, how, what? Like when someone's like, whoa, I don't understand what Agile benefits me as a product manager. I mean, as soon as I like, Got done being taken back by that question. And, and I, I regained my footing. I think, I think the question I would ask them, like right off the bat would be what, what do you think Agile is? Like, what, what, what do you think? You know what, what I mean, it's, it's the same questions that I that to apply to the project manager as well. It's like, well, what? Oh, agile doesn't work for me. Right. That's agile doesn't work here, that kind of thing. Mm-hmm. Like, oh, you're a purist. You wanna do a you wanna do pure agile, whatever Pure Agile even means. Right, right. Like what you got a problem with the principles. Or the values, like really like, tell me which principle, which value I, but if I'm, if I'm gonna actually seriously engage somebody and, and not just be looking like I'm trying to dunk on them I would ask them like, well, what specific principles or practices that you think are agile practices are, do you have an issue with well I think sometimes though people that are spouting these things, I guess they don't really know the agile principles, right? So maybe what's in order for really all of the above senior execs, middle management, project managers, and, and maybe some other roles that we're, we're gonna get into in a minute just explain to them what is Agile, right? Mm-hmm. Why, what and the why behind the ways of working in Agile way. Once you explain that to them specifically, the Uh, the, the product folks, they should understand that they're already doing it that way. Right? The, the last persona we talked about people in in companies that are already aligned in an agile way, right? They should understand that, that if you weren't doing that, what would be the alternative? Mm-hmm. So I think some knowledge sharing is in order here for us to kind of work with these folks, right? it it's no good just saying, well, you're calling me a purist, but you don't really know. Well, that's true. They don't know, but what, what do we do going forward? So I think that's, that's probably a good thing to have some induction into Agile for these guys. Now that I'm thinking clearly about this, the first question that probably you might wanna think about engaging with is just a, a general opening, the opening the door and letting them say whatever they want to say. You know what, can you, can you elaborate what you mean by purist when you say purist? What do you mean by that? Right. You know, in the context of Agile software development, I would, I would boil it all the way back to what the manifesto says, like the manifesto for agile software development. You know, in the context of agile software development, what do you, what is a purist? What, what, what does that mean to you? You know, just an open-ended question. Let 'em start throwing out all their painful stories and memories. You know, I, I think that's great because what you'll find, I suspect, is they're grounded in some things that aren't. Accurate. Sure. You know, they may say, well, we must always work in two weekend increments, and that that's not right. Mm-hmm. They may say that where everybody knows that's, that's not necessarily what the scrum guide is saying. They might start telling me about their PI planning. That's right. They might do that too. They might say that. Right. So yeah, I think that's a great way to open is, is just engage in a dialogue and say, what do you think a purist really is? Why, why would you say that? Which of these principles. Make you think it's purism that we're really, we're, we're going with but you know, I still stand by the fact that people, that when they say that, well, not only have they never, obviously they've never worked in an Agile way, but, or, or, or not recently. Uh, but they don't understand what it is. Yeah. So let's make 'em understand what it is. Yeah. I wonder if there's a good. Like, just like 10 minute what is agile stuff? There is like the agile manifesto explained, kind of well there, there there's are a couple of things, right? So I, I think if you look at. Things like lower level, if you look at what is Scrum, things like that, you've got those beautiful animated videos that Hendrick Knidberg has done. Yeah but recently I came across another set which it will come to me in a minute, but they were fantastic when it comes to looking at the agile principles. Yeah. And. What people think they mean versus what they really mean. Yeah. So people's distortions of these principles, it's by it's by Sjord Nyland and he created this, this pdf called Uncommon Sense. Mm-hmm he goes through observations, what principles they aligned to, and why people think what they think. Mm. You know, it's fantastic. I strongly recommend it. I went through it with one of my teams this morning and we didn't finish in the time box we had, so we're gonna revisit it. But it, it's awesome the way he does that. He says, when a manager believes X, y, z, what really happens is, you know these things, right? And has these unintended consequences. So I think that's important too, because what we're not doing is, is, is playing the blame game here. We're not saying, well, you are saying this because you want the. We're not doing that. We're simply saying, if you believe something, truly, yeah. Then if you are enacting on those principles that you believe it has these unintended consequences. That they're not really. They're not expected to know. Mm-hmm. Uh they're not a ans in any shape really. Right. They're certainly not somebody who's seen various teams at various organizations. Yeah. So they don't have the experience so we can call these out and then what Sue does is he says, well, so that behavior aligns to this principle. Yeah. And therefore, If we do it that way, I think we have a better chance of making sure that people understand what the principles really mean. Cuz they're not necessarily literal in that sense, right? Mm-hmm so yeah, I like that. I like the way, the way that's, that's done it's some intended unintended consequences might be things like missing market windows. Mm-hmm or long time to market because we're not going in these time boxes or things like ha ending up with in feature fog or over-engineered product. Yeah. Things like that. Yeah. Which people who have not worked in an agile way, product folks, they don't know that. Yeah. Right. They don't know even when they're going through that. So you know, I think that's, that's really where we wanna. Kind of end up yeah. let's cut over to the other category that I have observed someone actually using this term, which is external consultants slash software vendors. The person I heard was worked for a very large company, a very large corporation that, that sells a very well known tool. Tolus actually organizations, that individual was one that, that was said, oh, we're creating this, but you know, we can't all be agile purists. I can't remember. I wish I could remember. I, I don't even know if I could find the presentation online to show it. But I think what the individual at that very large company that sells a very well known tool was trying to say is we serve a large market. People are different at different stages of their agile transformation. So, our tools have to take into account people that may not be doing agile. In the exact way that we know that is the best way for them to do it. Yep. You know what I mean? That maybe they're not doing scrum by the book. Maybe they're doing kanban but don't have any actual kanban metrics and you know, whatever scrum ban, whatever you want. Maybe they're doing Scrum and calling it Scrum, but it's actually waterfall in it. Anyway. He, the point was our tool has to be flexible enough to where we can sell it to all those people. Yeah, that's, that's what he was saying. But it didn't come out like that. It came out like. Listen, all you purists need is stop complaining. We need to make money. Okay? That's the way I clearly heard what he was saying. But the point is, if you're buying a tool, right, that to supposedly help you with your agile journey, right? You should question and inspect the people selling that tool to make sure that because they're trying to make some money off of you, they're not actually holding your business back. Same thing with consultants. Like consultants I've heard many, many times with consultants, if you're asked to do something as a consultant and uh, you don't know how to do it, you just say yes and then you come back to home office and we will teach you what you need to know. Like never say no. I don't think that's a good strategy. I think, I think never saying no just leads to. Burnout. It's disaster, I think. Yeah. I think it's eventually going to lead to a, a train wreck in which you are a passenger on that train. I, that's right. No, yes. I don't think it's a great strategy, again, hey, do your consultants that I want to hire for this project, do they know agile methodologies? Yes, sir. They certainly do. And you know, they have no idea. That's, that's, that's what I'm saying here is like if they're resistant to, Hey, we should have daily standups, What, what do, what do you mean? What I need hands on. Keyboards. My people gotta be coding. That's right. Oh, we want efficient quotas. Yeah. It's time for meetings I, I can look, I, I can certainly relate to the former side, which is having worked for a a large global vendor mm-hmm. Selling tools, which is essentially in a one size fits all kind of environment. Yeah I, I think where when you inscribe this little episode with this gentleman, lady who basically said you are a purist, right? Dot, dot, dot. Yeah. Chances are very good that they themselves are not an agileists, really. They feel nervous in front of Agileists. Yeah. So they're guarded and they're saying, well, look, my tool is so flexible. It doesn't necessarily conform to what you're looking for or to do, but we, we sell to all these other people, right. These big Fortune 100 companies or 50. Right. And so if it's good enough for them, it's gotta be good enough for you. Yeah, I know. I did that as a demonstrator of a product. Is that the, nobody ever got fired for hiring ibm. Yeah, exactly. Okay. That, that's the, that's exactly right. Yes. Yes I think the trick is when somebody gets good at this or they're gonna listen first and speak last. Right? And they say, let me know what you're looking for and let me tell you, or show you hopefully how the tool can be tailored to do what you want it to do. Mm-hmm. Forget about being a purist, right? Yeah. You are just simply implementing whatever you're doing in a way. That might be quasi agile doesn't really matter as far as the vendor's concerned. Mm-hmm. So that's on the, on the vendor's side. But on the consulting side, I completely agree. There's some very, very dubious folks out there with a clock in their hand saying, okay, we can, we can come out and do magic for you. Right. Or some of them don't even take the clock with them. They borrow the customer's clock to tell them the time and charge them for it. Right. This, this is terrible. Holy man. The state of the industry is in that phase right now, I feel that it's gonna get shaken out because we're doing so much disservice we, as in agile consultants in general. Mm-hmm. Right. Of dubious expertise. Oh man so yeah, I agree with that. I've seen that several times when people come in and say, I know what you need. You need this. Yeah. Have you ever actually implemented an agile transformation before or even been part of one? I didn't have any time, there was a lot of people on the call cause it was a global event. If I had more time, I would've, or if I actually also, if I would've been in the room, I would've dug in to ask him what, what, what alternate approaches, what modifications to Agile do you propose? In order, in order to, to, to bridge the gap that you see and, and, and, and for the reason of calling us purists or throwing out this derogatory, it's, I'm me. So I would've, I would've cut him in. I would've sat him in the back. I would've gave him a little cut just to let him know, you know? Yeah. Line your, yeah, yeah. Line, line. Your knife with salt first. No, no, really, I mean, The, I like that question. Uh I might have led with the question of, well this, it's interesting you say purist. What do you mean by purist? Right? Well, you said that already before. Yeah. Like what is their opinion of what a purist is? Is it just somebody who wants to implement Agile in some way? Or is it somebody who's going to dogmatically follow the scrum guide or mm-hmm. Or what is it really? Right. And if their tool doesn't do one of two of those things, then you kind of question the tool. Yeah. You know, the decision to implement that tool. Just go back to stickies and sharpies. Yeah, I think we probably beat this up and up. I, I think so. another category is siloed team members. Like if your, if your organization has silos around teams or if you use component teams or, or if the specialists, for example, sit on one team, like all the architects sit on one team, or all the QA people or the testers sit on one team, that kind of, that kind of uh, set up. I can see resistance to agile from that perspective because those people are used to working in a very structured way of working and now you're coming in and you're changing it. And also depending on where these people have worked in the past. Or what other , implementations of agile, you know what I mean? What people rolling out Scrum or safe or whatever right. Badly practices have that they have gone through in the past, have affected and colored their understanding and their opinion going forward in the future. I want to talk about like the, the team members that may be that may be specialists like u I UX people, or b u ui UX people really shouldn't have any problem like dealing directly with a customer. But architects, bas, DBAs, specialists like that and with a, with a slash in the middle of this category to also say, QA people and testers. Yeah. Not even add DevOps. Right? They could be a, they could be a team by themselves and now you're in a queue waiting for your stuff to be deployed in production. Right? Yeah it's so, yeah, I agree with that. You know, I think sometimes what happens is the organization is measuring these individual groups. Differential. Right? So they're saying, well for developers, what's the, what's their criteria? Right? As soon as something is done and available to be deployed, they're done. But it's not deployed yet. Yeah. So income, the DevOps team, who is going to deploy it at some point, but they're busy working on other things. Yeah so this goes back to the, the whole way of structuring teams and so forth, right team members can be frustrated as a result of that. Mm-hmm. Because certainly those team members are understand ultimately what really matters is delivering working software of good quality, right? In a timely manner to the customer rather than we're, we're done. When we're done come up with an artificial d o d. Right and, and these people are your friends actually, because listen to them, listen to those pain points that they're they're relaying to you, right? Uh, I think there's gold there sometimes, right? Yeah. Listen to them and act on those that can be quite valuable. The question there is what do you propose, how should we modify our implementation of agile, whatever it is Yeah. To, to suit the concerns that you're bringing up? I dunno if people are gonna have a problem with me saying implementation Agile, meaning whether you're doing it scrum, or whether you're doing whatever. But the if you're, if you're following, it doesn't matter what you're. Implementation is whether if you're following the principles and you're committed to the values, you know you should be okay. But I feel if you can roll back to start with that in the question is, hey, do you, do you, are you aligned with these? Right? Like, let's talk about that first. And now if you're talking about techniques, We can flex techniques, we can talk about techniques. Exactly. Yeah. I agree. Yeah. Yeah. Just so those listening one of the things you could do is you could have team members in bed with teams. Yeah. So these are specialist team members, just as on an as needed basis even. Mm-hmm. Right? So you're not necessarily saying, okay, let's just have an individual from let's say um, UX or, or DevOps. Sure. Embedded within your team for three days because. Chances are you may not have three days worth of work for them. Right. You don't know that. You might, you might have more, you might have less. Yeah. So on an adita basis, bring them in and then they float around. Right? Yeah. So they're the, the floaters. Mm-hmm. There's many different ways to slice this. Right depending on the nature of the work, I mean, if you, if your work involves a, a heavy UX component, you might have them embedded in there most of the time, or even full-time. Yeah so techniques wise, yes. I mean, there's a plethora of different solutions there I, I think the point is to, to listen to the team members to find out why they are objecting to. The agile ways of working, right? Yeah. QA specifically, like only, only this interests me, only because it's in my background. Like I could completely see them resisting, especially a team. The where like stuff is chucked over the fence, oh God. You know, to a QA team to go through the QA phase. Mm-hmm. You know, , Hey, we're gonna freeze all code changes and we're gonna go into a month long cycle of testing or something, whatever, right? Yeah. Um I could see the QA p initially being hesitant of moving to iterative development like I was on a QA team one time earlier in my career where the developers would work basically right up until the last day of the sprint and never give the testers anything to test. It wasn't like you were peering on things because they, because that company had implemented agile. They, they basically said, the management came down and said, you're using Scrum now, and these are gonna be your teams and this is how it's gonna go and this is how long your sprints are gonna be, and this is what work you're gonna take in during your sprint planning. You know, it's pretty much prescribe every Yeah. That, that was what, well, that was the, that was the management's idea of what Scrum like. It had nothing to do with Scrum or Agile. Right. It had like, it had to do with the development. Didn't want to write PRDs anymore. And they didn't wanna do a bunch of documentation at the same time as a software and they didn't like they development wanted to eat pizza at seven in the morning and not wear pants to work. That's basically their implementation of, of, and a lot of people on the team QA members specifically, would get a bad taste in their mouth going to other shops after that to be like, oh boy, you guys are agile. Oh, you know what I mean? But it's not, it's nothing anywhere near what you know, the Agile is in principle. Or, or what agile needs to be in practice. Right. I mean, it's just, that's just a, what I call a, a wonky or a bad implementation of quote unquote agile. Yeah. Yeah. I agree. And that's so common too, by the way, right? Developers are saying we're done when they're done developing and then checking it over the wall at Yeah. You know, at qa and then reporting these metrics. So we, we are done. We're not really done. Well, the other thing, which , QA team members will find useless advice is well, you've gotta move to a continuous testing, or you've gotta add more automated testing. I mean, you've gotta quote, shift left with your testing efforts. And the QA team members are very frustrated at that because it's the, it doesn't help. Like, yes, everyone agrees like, oh, So see, they'll bring in somebody or you know, again, one of these vendors or their consultants or you know, some new engineering manager and they'll say, wow, we gotta shift lift and we gotta have continuous testing and we gotta double down on automation. And, and everyone will do this with their heads, right? Oh, they'll bob their heads up and down. So like, oh, so good. So like, they're just watching Simon Sinek oh, so inspirational. And then no money goes to it. No budgeting goes to it. Nobody tries to train any of the QA team members. That's just lip service. Yeah. Yeah. Right. Makes everyone feel good. But then again it's, it's, these people are seen as well, you're just, you're just resisting change, you know? Well, it's the, it's the same as middle managers. It's like, well, did you train them on right now? Now that you own all these quote resources? Resources, human resources. Now that you own all these quote resources that you hire for the organization, like you have all these people that you've hired and they work for you on paper. You're their org. Org chart, direct, you're their boss. Yeah. Reporting boss. But. They don't work with you on a dayday basis. They're distributed to the teams that they, that they serve as a test , expert on. So, ha has anyone talked to these managers and sat them down to say, these are the principles, agile, this is what typical org structures look like. Now that we're using distributed, decentralized type of we, we did a whole podcast on team topologies it behooves you to, to go out and learn a little more about how different organizational structures. treat things the old, the old pyramid, we, we might get into that in the Deming podcast. The old pyramid org structure chart really doesn't help you. No, it certainly doesn't. I, I fully agree with that. You know, I, I think, well, one of the things that's always difficult going into an organization is looking at where they're at. I hate that term. Meet 'em where they're at. Yeah. Yeah. But figure that out and then say, well, I, they really don't know anything about. The principles or anything like that. So give them an induction in Agile foundations. And typically you'll find people say, well, does that mean a half hour meeting? Well, no, it doesn't. You know it at, at a minimum it's a half a day, but, ideally a full day. Yes you could do worse than just do the Agile Foundations course that the Scrum Alliance has, for instance, I know scrum.org probably has something similar, but Right. So do that. But they have to commit, they have to commit to these middle managers or even, even senior managers for that matter. Yeah, you could do a little shorter of a stint there, but CM Manager have to understand that too. So they don't just come in with their own interpretations or. Misinterpretations Yeah. Of what Agile is, and then they just drive down that path. Right. So you need to kind of have a level setting there. Mm-hmm. And that is often not done. Yeah. Is what I find. Well, the funny thing is like LE leadership teams and executives and when there's like a big executive changeover or a CEO changeover, whatever they do, like leadership retreats and stuff like that to, to talk about what, let's align on vision, let's align on this kinda stuff. And then, and I've never heard anyone doing like a process type of like treating with the same vigor of like, Hey, let's redefine how our teams internally are gonna work together and that's I don't know whether that's a failing of the, of the modern organization is not inspecting the system. Even if we dial all the way back to Taylorism, which invented modern management, like the, in taylorism management's whole job was to inspect and adapt the system. Yeah, absolutely. Yeah. Nobody else could do it. No, nobody else could do it. That's correct. I, I, I think we're falling foul of you know, this, this. This modern, how should I put this, this, this paradigm where there's no time to learn, there's only time to do. Mm-hmm. Right? Uh we have to get this done by. Right. You don't have time to waste on all that stuff. All that mumbo jumbo. That's the problem. There's no time to sit. Just pause for a bit and say, let's all at least get on our level playing field of what we're trying to talk about here. You know, and then when you add in dubious consultants and you know, these vendors that we spoke about earlier, it just does our customers and our clients a disservice. Yeah. On, on a massive scale. I'm glad we can end this podcast with some hope for the future. There. There is, there is hope. There is hope. If you're not finding it in this podcast rewatch it. No watch it again. You watch it again. But no, definitely stay tuned for another podcast where we're gonna go through some of this stuff in more detail that's in a different way. And also check out team Topologies and agile doesn't work here. Those are two that are, are in, in a similar lane that we're in right now team Topologies is, is talking about the, the org structure and better ways of arranging teams that, that work with each other. And then uh, agile doesn't work here we talk about the same kind of underpinnings of people uh, of traditionalists or, or pragmatists or people that are just kicking, refusing to change and, and, and what to do. But The big takeaway from this is if you ever now that you hear it, Now that you've heard us talking about it, right? If you get referred to as a pierce, if you hear somebody slinging that derogatory term at you, you should definitely, like the very first thing should click into your brain of, oh, I heard Brian on a podcast one time, say, I should pull the emergency break on this conversation and say excuse me. What do you mean mean that's right by purist. Exactly. Don't, don't bring out the gloves yet. Yeah, right. Just listen, first, ask these questions and then you'll be surprised at you know, where, where the conversation goes. We may even do a separate podcast and due course on the new. Methods as per like management 3.0. Mm I'd be interested in that. Yeah. Yeah. So stay tuned everybody, and subscribe and like, ooh,