Arguing Agile

AA203 - Hating on Agile: Developer Frustrations with Agile

• Brian Orlando • Season 1 • Episode 203

Share episode

We're exploring the growing anti-Agile sentiment among developers as the agile-industrial complex has stitched together a grotesque imitation of what was once a vibrant movement. 

Like Frankenstein's creation, what began with noble intentions has transformed into something both villagers and developers flee from in horror!

Before lighting our torches and brandishing our pitchforks, we examine the common complaints: lightning-rod meetings that drain life force, the monster of micromanagement wearing agile's skin, the cruel illusion of self-organization, and the chains of cross-team dependencies binding teams to their suffering. 

We dissect the organizational structures that, like misguided scientists, fundamentally misunderstand the natural advantages of agility, creating abominations that shamble through corporate hallways.

#AgileLeadership #ProductDevelopment #TeamEmpowerment

References:

  • AA199 - W. Edwards Deming's Profound Knowledge for Transforming Organizations, 2025
  • Eric Ries - The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, 2011
  • Jeffrey Bezos - Bezos API Mandate, 2002
  • Who Moved My Cheese - Spencer Johnson, 1998
  • Extreme Ownership: How U.S. Navy SEALs Lead and Win - Jocko Willink, 2017

= = = = = = = = = = = =

YouTube

= = = = = = = = = = = =

Subscribe on YouTube

Apple

Spotify

= = = = = = = = = = = =

Toronto Is My Beat (Music Sample)

By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)

CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

So today I want to talk about an announcement that has got everyone up in arms. That the PMI has bought Slash merge with slash. Acquired. Yeah. The Agile Alliance. And I wanted to get your take to see if I could find somebody in the world that cared because I didn't care. I saw the news and I found it very interesting. So this quite topical. There's been a plethora of stuff out there from people that are basically saying yay or nay, right? Oh, so we're gonna delve into it today. Oh, I hope you have an opinion.'cause I, I have some. Well thank goodness I, I hit our music. I don't know, that was music. Interesting. All right. So here, here's the article, Agile Alliance joins Project Management Institute PMI, January 3rd, 2025. So it wasn't that long ago. We don't really like ride trends on the podcast that much. And , this is the launching point for the Revisit episode. Exactly. I feel like I'm gonna represent on this episode what most people are saying. Which is, I could care less. Most people are already that Agile ship is sailed. I follow many development communities, a lot of developers are anti Agile. Yeah. Because it's been co opted by modern day management as a tool of control. And they just use the Agile terms. Yeah. But still do all the PMI, project management, old school type stuff. Just to stay with this for a second, let's look at the article. Agile Alliance joins PMI. It says there's some fluff here about the world leading authority and project management and the people who've taken your money for many, many years to have you what like the old PMI. way back in the day when you had a PMP certification I remember it was a big deal that you had to actually work and prove that you were on those projects to keep your certification. Did that soften over time? I don't believe so. I don't think it softened. I think what's happened is there's been a lot of quote unquote, enablement companies that sprung up over time that just say, Hey, look, just attend our class and we'll show you how to pass the test. You know, and as far as industry, basically, exactly, and as far as making sure that they had the Prerequisite hours of experience before applying you're taking a chances. Are you gonna get audited if you do? But you know a lot of people just take the chances and roll the dice I always thought the pmi certifications were like somewhat stringent about auditing your stuff They used to be now. I think it's relaxed quite a bit over the years to be honest I mean, that's what i've seen at least talking to people as well that are recently minted ones I used to be part of the mentorship group in the tampa bay pmi chapter just to make sure that we can enable people locally to be able to become PMP certified or CAPM certified. And what I learned is the frequency of audits have gone down for what it's worth. I'm sure that has something to do with the cost of benefit of how much money it takes to actually audit I don't know, I'm not really trying to make a statement cause again, I don't know if I really care about any of this stuff. just to read some snippets from the article. It's part of the process, the managing director and the board members, I'm assuming the Elected board members and whatnot. They all can keep their positions and they join the PMI now so well, yachts for everyone, basically. I don't think there's any yachts even involved in any of this. So Oprah comes to my yacht for you, you get a yacht and you get a yacht. No, seriously though, I personally think, and again, this is just my point of view PMI has been trying to become relevant or stay relevant for quite some time. And this is just the latest thing is like, they've seen membership. Not come on as strong at the same pace as in the past or renewal, rates drop substantially I know personally of several people that have said i'm not going to pay them anymore So that I think this kind of makes sense when you think about The easy way into the agile space. I know they've came they came up with their own certs as well into agile, but this is like The Agile Alliance or Scrum Alliance are the only two, or Scrum. org too, I guess, right? But the other two are legit bodies that certify people and have a bunch of experts contributing to that, right? So the Agile Alliance, for me, really is all about, You go to them to see what events they're putting on, where those events are, and that's pretty much the end of it. So, I did a bit of poking around, we need over on the other side of episode 200, We need to make a slight adjustment to the working agreement which we're doing on camera without talking about it for the first time. I feel the working agreement needs to be like, the company names organizations need to be fair, like fair choice for naming and shaming on the podcast. Whereas people, individual people, I am not going to use the podcast as a banner for attacking people. No, no, that's not what we're here for. I don't mind saying that like all the people in here like there's a lot of people that are on their board That are trainers that basically make their money off certifications Now those people are moving over to pmi which i'm sure that at some point when they move over to pmi whatever pmi is doing with certifications It just makes sense that like now I can train over here on the scrum side Of the house. And now I can train on the PMI side of the house and somewhere those two revenue streams will connect to make a larger revenue stream for all these people that would not be impacted by this. But taking that simple view aside, I want to read some sentences from this release announcement here. this little marketing thing, it says modern project delivery demands fluency across a continuum of delivery practices, enabling professionals to choose the right approach for each project. Successful delivery requires a combination of skills and knowledge tailored to specific contexts. So that's what Agile is. It's a delivery. Practice, which right there, that sentence, I fundamentally disagree with that sentence, but also like all the people attacking agile, like this, I feel we have a, there's a fork in the road now. Do I want to attack agile for being like just a cash grab on delivery practices or do I believe in it as like a fundamental mindset that you should be running your business off of, right? That fork in the road. Is going to basically, that's what we're going to talk about this whole podcast. Cause I want to talk about, we had already planned to talk about why developers are so negative on agile and it's difficult to talk about why developers are so negative on agile without including scrum because most developers they just have bad experiences, all across the board with the quote. Implementation of these delivery practices. But none of that corresponds to any of the principles of the agile manifesto. And if you're going to say like in the agile alliances website, it says like, Oh, we're, we're an organization that cropped up because we wanted to promote the agile principles. So how does merging with the PMI, the vision, the strategy is not clear to me. Of how that enables, you know what I mean? Like I feel that should have been, they should've spent a lot of time crafting this release announcement to talk about how emerging with PMI can enable a strategy of bringing better agile to a broader audience. That's not what I read here. What I read here, I read as a product manager who says, okay, the market has been re segmented. Where Agile is taking market share away from selling PMI widgets. So now we're gonna buy the top organization that we can buy promoting Agile stuff to say, oh we were Agile all along. These people were wrong the whole time. I think the point you make is valid. I think part of that is also The PMI really was late to the party when it comes to adopting the agile ways of working. They were still talking about their eight, nine or ten, whatever it is nowadays, subsidiary plans and project planning, project management. So they were late to the party, but by doing this, they can now say, We're also agile. And the other side of the equation that you started off the conversation with, those trainers that are Agile Alliance trainers, or they were before the 3rd of January could now say, I can certify you and you'd be PMI certified. And it's exactly the same cert that you were getting before, but it's yes, exactly. So there's this sense of there's some legitimacy here now, right? Suddenly cause PMI's name is on it. Honestly, there's been a saturation of training providers to be generous, right? People that can say I have a class you should attend because you'll get certified and it'll be good for you There's been a lot of people that can do that lately not just in america's but also globally what happened and I think covid helped this along as well is a tremendous drop in the cost of taking certification classes and exams where you could get, for pennies on a dollar, you could get the same certification from an overseas R. E. P., Registered Education Provider. So because of the competition,, the trainers are struggling. They have been for a bit to try and stay relevant, try and make sure that they can survive let alone thrive. Right. And I personally believe that this is why the Azure network was bored because they, these trainers are, what can we do? let's just unite and create a platform where we can do a freemium version. People can get something for free.. To entice them into joining, and we'll make it easy for them to join. It's a dollar a day only. Right. Less than the cost of a latte. No, too expensive for me. Yeah. if it was like 50 bucks a year, I throw my money on it. And again, there are things that they could be providing to me as a product manager for my fee that I paid to the network tools and whatnot, that actually would be very useful that we talked about on the podcast all the time. we talked about with Alex the tools that serve as a community now, just don't do that. We like all the stuff in between teams, all the stuff at a strategy level, like none of the tools do that. They could have built, I mean, there's enough software development professionals that do CST. I'm not gonna, I come across flippant with the CSTs, but there are a lot of experts with deep knowledge in that network that they could build a tool like this, just with the money that falls between the cracks between them and their own teams and whatnot. They can build a really great tool to do this with integration, with Jira, with integrations, with whatever tool you use. Did I say Jira? Sorry, I didn't know. I didn't know if I said it. But that's not the route here. When you have a market that's saturated and has pressure on it from the industry at large where people are dumping on agile to begin with, as has been the case lately, the trainers have a hard job trying to sell themselves. And so collectively joining something like a union that you see From the perspective of legitimizing it. Everybody knows what PMI is. You know, what they bring. And then the other side of it is the actual network, but at the same time is saying, well, it's only a dollar a day. Look what you get for it, is what I'm seeing being advertised. You get access to number of CSTs, right? So they can help you for your own specific situations. You can ask them detailed questions. Dollar a day is a good price for that, but I feel like they're missing the boat a little bit here. And that is a lot of these trainers, when you really dig deep, haven't really worked in agile, like on a team, on teams of teams, they've become trainers. And what they teach you is, again, I'm going to get a lot of flack for this. They're gonna provide you with the book knowledge is how you do things until you go to the real world You know, wait, wait, I can't apply that here because it doesn't work in the real world. So what you just brought up I wrote some notes of what I've heard from developers. And we sat down before the podcast, we kind of arranged my notes and we do arranging of like the order in which we think it's important to talk about things, right? One of the things that you just brought up, I have heard was this no true Scotsman type of like Oh, you can do scrum, but no one ever really does. Your implementation of scrum isn't properly working or whatever. And then you're like, well, you're not really doing scrum. So To a lot of developers, it just sounds like the no true Scotsman argument where you're like, no matter what you say, I get to say, well, you haven't done that right. You know what I mean? Like I've done scrum by the book , and at every workplace ever been, I tried to move scrum back towards the way it's written in the scrum guide. So there's no extra added anything. And I always get the teams back to this place, but I've never joined a team that was using scrum. The way that I finagle scrum to become to be like, Nope, this is we're doing it right out of the book we don't skip things. And I mean, there's always productive conversations that come out of it. We're going to talk about but that particular category of most developers, they've never worked with a product manager that knows what they're doing with a organization that supports scrum with an organization that, that understands what they're doing. Like stakeholders have to be at the certain meetings that they have to be at and stuff like that. And there's, there's so many kind of do this or that, or do this and don't do that type of things that there's so many developers that just have never. Seen it. It works. Trust me. I think you're right. I think a lot of times where I've, well, certainly I can rely on my own experience or what I've seen is a lot of developers have heard of it, but also being part of fragile agile a part of pseudo scrum in the past, wherever they come from, especially those developers that are contractors you know, mainly from offshore contracting vendors, what they've seen from other companies Makes them cynical and they say, well, I hear what you're saying, but it never worked in my past. We tried, we try to do that. Did you really try to do that? Right? So that's where I think I've seen a lot of people just come up with the guards up, right? When you say we should be doing this, we should be doing that. And there are symptoms you can see that people will be Not vocal, not contributing, just going along, right? Because whatever you're saying this, but I've never seen it work. We did a whole podcast. Agile doesn't work here. Arguing Agile 83, Agile doesn't work here. And I feel that a lot of what we're gonna talk about today is not this no, it isn't that this is different I mean, are you a real like we talked a lot about management hang ups? Yeah in 83 We talked about incentives middle managers sabotaging things business incentives and the way that the business is organized kind of torpedoing how things are Our setup of organizational fear of failure that kind of you know me ego is that kind of stuff? But What we're going to talk about today, like the hangups that developers we'll use it. These are the arguing points, that developers will use. Frustrations. They have, we're not saying they're doing this deliberately or anything like that with malice of forethought, That this is genuine, but at the same time, they haven't said. I've never seen the environment where it can actually work right if they've been around a bit and they've seen that and there are a couple of developers I know in the Tampa area that vocalize that themselves and say, look, this works right. I didn't used to because we never did it right to begin with. So yeah, this, this is a different nuance on what we were talking about before. Also, one of the things not on our list that I heard they said most people in the field now, They've, they've never worked in waterfall. So when you say something waterfall, or when you compare something waterfall, it's meaningless to them. Cause they've never worked in an organization with a project manager who like gives you the work breakdown and says, you have to complete this by this time, . They've never worked in that. Everything's been relabeled with agile terms their whole career. They don't know it's this project management command and control mindset, right? Who's used new terminology. So all this is being assessed. All these failures are being assessed against agile, right? and really they're working in scrum. So really, they're assessing the failures of scrum and saying, well, all Scrum is Agile, but not all Agile is Scrum. So basically all the problems are directed back to Scrum or Agile. No, that's absolutely true. some of the younger folks out there. They've never worked in Waterfall before, but now they're working in Scrum labeled. But are they really working in Scrum or is it simply agile water Scrum or fall, basically. Let's talk about com complaint number one's, exhibit one. Yeah, let's talk about Exhibit A. I need to relabel, how can I relabel these to a quickly I can't. I can't, I can't. No, you can, I think you can go to the bullets list and say Google Docs is gonna. I don't know what I click control Z control Z that'll be the first thing that they'll say. They'll say, they'll say there's scrum has got all these ceremonies without, they'll say agile. Agile's got all these ceremonies. I got to, I got to go to my daily standups. Why do I got to have a daily standup? I got to do sprint plannings that are, it's just my tech lead telling me what to do. Anyway, I got to do retrospectives, which is all us just sitting around and writing up a bunch of lists of the same things over and over again those are not scrum problems or agile problems. Like those are just like organizational problems. And you have to find a better place to work. They will hear this, but they'll say shops like Google don't do any of this. They don't do any sprint plannings. They just have small teams that are self contained that have all the right people, all senior people, self contained talk directly to customers and pitch their own projects. And they're the most successful company in the world, Brian. So you don't know what you're talking about. Yeah. I mean, look, I get that all the time in my role, right? because people will just say, why do we need all this stuff? It's too much overhead. Just leave me alone. I know what I have to do. You've shared the backlog with me. I'm just going to do. Pop off the top of that stack. I'm going to go to the basement. I'll work on it. Don't bother me with all these meetings. Okay. But you're not learning what's needed. You're not learning how the need is changing. You're not talking to customers. So you've got people working on the same stuff under different guises. This idea of collaboration, right. And making sure that everyone owns collectively the output outcome of a sprint, that is something that some people find difficult to accept, especially those are those that are not like new people. these people are tech leads or equivalent thereof developers that have Been in the game for a while. We know what's needed here, right? Let me go get this done. That's all I need to do. And when it comes to a review or a demo we'll just throw it over to the product owner. They can do that. I piss off customers when I open my mouth. It's like, yeah, okay. But you need to be the person who talks to the customers. The customers need to be able to ask you questions, right? You need to get into the refinement where, by the way, I have customers in refinement, right? A lot of times that doesn't happen, but I do have that and they can ask questions. Sure. So it doesn't matter that they're not using my products now, but at some point there'll be in a sales pitch and they'll hear about my products. Anyway I was at a customer visit one time that I just went along just to hang out, just to see, Hey, I'm Brian. I'm a product manager for this thing or whatever. I'm not your product manager, but you know, this is, I'm here with your, we're peers is product manager. Product manager Bob, and the product manager said, Oh, I can't go to lunch. I got to stay here. I'm like, why? this is the only hour we have free , get something to eat. You're going to be wiped out after lunch. And he's like, no, no, no. This is my refinement time. And if I don't make it to refinement, then I can't trust them to have the stories that I prioritize at the top of the, yeah, I can't trust that they will be able to, the refinement done to have those stories ready. And if the stories are not ready by sprint planning time, then either our sprint planning is going to run super long or I'll have to make more time for sprint planning or we won't be able to basically the work for the sprint won't be ready. If I don't make it this refinement to help them, cause I'm the guardrails. It helps him stay on track. Yeah. And when you say guardrails, I'm hearing I'm the bottleneck. I said, I said, then your whole team should be here at the customer. Then. Doing a gimba. Every time you sure, every time you travel and going from the customer and hear their pain points, They should be in front of the customer. And he's like, well, I don't know if I could do that. I'm like, yeah, because that's the agility that we're talking about Well, maybe your meetings will be shorter if your customers. Had built this empathy for the customer and really understood like oh when we were at customer a Little timmy said, I don't know why like the child labor like He's like Johnny's graduating elementary school soon, and he said He's on H one B Visa and That's a little topical. 2025. We'll see how this ages in the future. If you were able in your sprint planning to say like this is the functionality we want to do, we want to add this drop down and let the customer get through process why faster and I want to do that because little Timmy said that getting through this process was terrible. we all thought that 18 clicks was easy enough, but little Timmy said that his little tiny fingers can't click that many times. And we got to make it five clicks or something those conversations can be shortcut. Whereas otherwise you have to sell development on. These things that you do every day on your development machine, you don't realize how painful they are to the customers because you never talk to the customers. Oh, dude, so there's so much there, right? First of all, if the development team was directly interfacing with the customer and the customer has a pain point, then the development team could ask that question or the customer could say, well, this is so painful, I have to do 18 clicks. What is it that you're trying to actually achieve? And so it's no longer about like going back as a product person to your team and say, we need to have a drop down. That's just the how part, right? What are you trying to achieve? And developers can ask questions. What if, what if you could do X? What if you could do Y? And the pushback could be, well that's too many, it's still too many key clicks. Okay, well we'll come back to the table with some other solution, right? That is valuable. That's gold compared to going downstream and then saying well, we need a drop down. Okay. Well, we'll give you a drop down. Then you take it back to the customer. The customer says there's too many values in the drop down. I get lost in there. Maybe it should have been a radio button. Who knows? It could be a multi combo box, whatever, right? So it's not about the how it's about not only is it about the what they need, but also more importantly, I think, is the why, why do you want to do this? Right? Oh, well, because every time we go through this experience, it saves 15 seconds and we go through it 1000 times a day. Yeah, that's why. So that's actually a pain point that we can align with, right? Yeah, trying to solve it. So I think it's important for developers to. Interface with customers and be able to ask questions and learn what the real needs are, what the real pain points are. The brave ones will also push back. Sometimes it's not about just saying yes, sir. No, ma'am. Right. Or sometimes you say, you want that, but you know, wouldn't it be better if you didn't have to deal with any of that and we could just give you a sub page over here or whatever the situation might be. So sometimes it's easier for the developers to simply ask the right questions, say no in the right way, or just say, well, okay, but what about this instead, instead of just plain blank saying no, much, much quicker. You know, having the intermediary as a product person, to me, that now you've introduced yourself as a product person as the bottleneck, because when a dev asks an interesting question, you're going to go, I don't know, let me get back to you on that. Okay, wait, right, right. You've introduced waste right here, right. Somebody asked me recently can I, can I take this site and make it dark mode and I said theoretically it should be easy to implement because CSS. But let me take that to the dev team and ask them because if the site is written in a way where all the CSS selectors are easily. Flipped, then no problem. I was like, but if all that stuff's hard coded, then it's going to be a huge issue. If the backend code is a mess, And they never implemented it like that in the first place. I wouldn't know as a product manager, I wouldn't know that they didn't take a lot of diligence to implement this control or they just like grab something off the shelf that they don't have a lot of control over just to kind of move things along. I wouldn't know. So I had to check with the development team, a better thing to do would have been to invite like my tech lead or my lead developer a rep from the team to that meeting where I was talking with the stakeholders so that we could just answer the question right away and be like no, all of our stuff is done where we could hook up light dark mode. We just never implemented mode selector, the little box to select light or dark, super easy, 10 minutes or no, this is heavy refactoring and then I could just tell the stakeholder right there, like it looks, these are the things I have my roadmap ahead of that. And they're all way more important than that. And I could just level set right there on a call. look, I got a lot of more important stuff to do. I want to get there eventually, can this wait a quarter? And then the business person probably would be like, yeah, all that stuff's more important. You can wait a quarter, whatever. But I am leading to a place where eventually we get to light mode, dark mode, I probably would ask some more questions. I think the important thing is you're having those straight off discussions earlier with the right people. I think , the important point here is developers complaining. There's too many meetings because we've implemented scrum, but you're just implementing like scrum out of the box and standing up all the means just to have all the meetings. This is one of those a shoe Hari things if you've come from like chaos development or nothing no process at all and you set up scrum Out of the box sure it might be annoying for a while while you're saying no you have to have A retro and a sprint demo and whatever. And you're like, I don't understand what is even in a sprint. How do I even get users? That stuff can be scary, but anybody complaining about meeting overload, any developer complaining about meeting overload, try this, don't have any of these meetings that a retrospective aside, don't have any of these meetings that a customer is not part of. Okay, you don't want a daily stand up? Fine, don't have a daily stand up. Don't have a daily stand up as long as when someone says they're stuck on something, you're going on a slack and having like an impromptu huddle. If you're getting together impromptu when Things happen if you're basically doing like the pull version of a stand up, Rather than like a daily cadence just on a set schedule what happens come rain or shine Yeah. if when somebody picks something up and opens up a repo, they never been in for the first time, they get another developer to look over their shoulder. when you want to do a PR, you say right there, Hey, I need a PR. I need someone to look over my shoulder and do a PR. You get someone on a call right there. You know what I mean? If that's your version, I agree with you. You don't need to do, you probably don't need to daily stand up But yeah, I think at the backbone of that, it was really just having sound working agreements because if somebody's stuck on something as a team, you could decide if anybody's stuck on anything for, let's say more than an hour, put something in Slack or whatever you're using, right. to collaborate and somebody can help you. Wait till the next morning because you're doing it by the book, right? And then raise it at the daily stand up. Yeah, there's a lot there. the topic that we're talking about is like, well, we're going to have all these meetings and they're all one size. So it's all like, oh, the scrum guide says, the scrum guide says we have to have them all. And they're a waste of my time, right? Well, if you're finding meetings are a waste of your time, and you're not using the retro to either correct the meetings or. To bring the customer into the ones that aren't useful. So that thereby making them useful or something else if you're in a bad working environment and there's no way of improving it, there's one piece of advice on a podcast. We always give. Keep that resume updated. Most of the time though, when people complain about having too many meetings or meeting overload, it's. they say, well, we already have all these other meetings. We have collaboration calls, et cetera. And then we have these scrum meetings. And when you dig down deep enough, you'll find that if they did the things right during the scrum meetings anyway, that the other meetings basically are superfluous. Why are you having all these of them? Like, you don't need them because we've always had them. I've seen that too, where I've been in organizations where they have like all engineering, The team stand up and then all the engineers together have a different stand up Why would you do that? if you're going to the agile principle of each team creates a process that works the best for the team, that could be this whole category is like, Hey, you know what you scrum, but you know what, if you don't want to use scrum, if you want to use combine, if you want to use whatever, if you don't want to use any process at all,, do whatever works for your team. Every team should have their own processes that's tailored to fit the team. By the team for the team. And if that's seen as extreme in your workplace, you have problems with your workplace. We've taken scrum completely out of the equation at this point, because I have teams that use combine, use combine well, right. And all the events and everything are on demand. We have a daily standup. Sometimes we do it async. Sometimes we don't like if everyone's just kind of clicking and is on task and unblocked and whatever, just pulling the top item. We just say, Hey, we're, we're working. Everything's fine. You know, and that's it. I see a lot of people say this., we've suggested a few things use the process. It works for you. Use the meetings that work for you. If the meetings aren't productive, bring it up in your retro, make the meetings productive. If customers aren't in there and it's supposed to be in there, you get the customers in there. And if you can't do any of that, keep that resume updated. a lot of people stay in the shu stage for a long, long time. People don't realize that. That's actually something you can just quickly jump out of. Well, the student has to want to improve. That's absolutely right. Or to improve in the shoe stage. So meeting overload, always going to be the first thing everyone throws out. The next thing people are going to throw out is agile quote, agile, they, they usually bring up scrum when they say agile. Agile is just micromanagement, disguised with another word or pro typical project management, disguised as what we would call waterfall. Yeah. The complaints here that you'll hear is that the daily standup is a status meeting. Right? Nothing ever changes after retrospective., we say the same problems over and over again, and nothing ever gets resolved You're not allowed to take anything out of a sprint. And if you're scrum, you're not allowed to take anything out of this. Management will tell you what's in the sprint and then keep adding stuff to the sprint. As the sprint goes on, they'll keep adding stuff without taking stuff out, the work in the spring is up to the team, so if they feel like something can't be done or needs to be moved out, they should move it out. They should be feeling empowered to do that. but a lot of shops, they're not real quick over. It's like the other thing that aggravates me about this category, not micromanagement, well short of micromanagement. But that goes hand in hand with this category, I think we're going to talk about this later is. The re segmentation of the market, like what PMI is reacting to PMI is reacting to the re segment thing of the project management market to pull the agile stuff out and be like, well, we don't need project management in whole, we don't need it. We can just work directly with customers, work back and forth. So basically the customer has their own little delivery team and we'll just deliver software on a regular cadence. You pick what the highest priority thing is on the cadence. And then , at a certain cadence, you will be getting finished working quality software, right? there was a resegmentation of the old project management software development. They sort of pulled this little piece of software development out of project management and said, Oh, we're agile now. And then product management. Soda was born in parallel out of the GM role of an organization that was dedicated to like a single suite of software or whatever. And then at some point. The product management side of the house said like, Oh, we were never agile. We never did any of these agile things. We never followed any of these agile principles. And they're trying to rebrand themselves as like, Oh, we always. We're doing something. it was never agile transformation that we were doing to make product work. It was always a product operating model transfer it, it bugs me because it's, there's a lot of stuff in here. this micromanagement, disguised category that also can co opt and destroy good product management. Practices. So , like management throwing stuff into your sprint when the sprint is already kicked off which basically means Management is not letting you keep a prioritized backlog for the team to pull the top off of and say, Oh, these things are the priority. We're going to take as many as we think we can take and do in a sprint. And then boom, that becomes our sprint super clean, cut and easy way of managing your work. But when you're, Just relabeling terms like that practice is kind of nuanced and it took me a second to explain the prioritization of an ordered backlog and pulling it in and creating a sprint from it. That's not going to make its way into the nomenclature of the micromanaging management culture. So some of product management is not. possible in this type of culture, that's a culture where you're instilling this idea that whatever I say right now is important. Oh, and 10 minutes later, I can come back to you and say, well, that's changed. So deal with it because they will turn that around at the team when the team says we're already sprinting, right? And it's okay if you want to change things, but you're adding something, take something equivalent out. It's like, you're agile, figure it out. So they'll use that against you. You're agile. So I can, I can come to you anytime and I can change what you're working on and you shall not complain because you're agile. Right. And they missed the point at that stage because that whole opportunity cost discussion that we have. Yeah, I'll bring this in, but at what cost? I like that this bald face micromanagement, like they're doing that while also setting inflexible milestone deadlines. Sure. And then saying like, you have to have this done by this date. And I'm like, but that date falls in the middle of the sprints. I don't care. Get it done. Right. These incompatible worlds someone who's just in the shoe phase of shoe hurry, just trying to learn there's no, you, there's no way. I can't imagine how you learn. With this kind of stuff layered over the top of like, Whoa, we're agile, but we're, we have deadlines we're agile, but we don't get to take stuff out of the sprint. Oh, we're agile, but we don't get to choose from the top of the backlog of what there's so much in here that like, I understand what I started the podcast being like, these points are ridiculous as we talk through them. I'm like, these points are completely valid. They are totally valid. And yeah, I mean, to your point if you're agile, but right. This is exactly why team members basically become jaded after a while. And so it was supposed to be agile, but really, or there's no such thing as agile. Yeah. Well, or it doesn't work here. That's the other thing, right? maybe as you may work in your organization, but it doesn't work here because we tried it. Well, I mean, did you really try it? How many conversations about like, we need more velocity, like how many of those until you just believe agile doesn't work anywhere. I can only imagine the developer who works at let's say you work at a FinTech or you work in finance or whatever. And you know, you work at one place for three years in a place five years in another place, every place is going to be using agile terminology. You know, going to be doing sprints, this kind of stuff, and they're all going to have these problems. Yes. You're absolutely correct. And I think we've talked about this on other podcasts. I mean, part of the rationale is people that are making these decisions, Make the senior level managers didn't grow up in an agile way or agile ways of working. So that's what they know. It's been successful for them and they're going to continue doing it that way. And part of that also is we talk about training teams. But we don't really often talk about training leadership, right? And that's where it starts often potty training leadership. Well, they need to do a training wheels on longer teams. So like another one that we don't normally talk about on the podcast, which I think is a neat category and we're going to take two seconds to talk about. It misalignment like agile slash scrum. Mainly this is leveled at scrum. So let's just say scrum. Scrum is misaligned with creative work. They'll say like software development is creative work. And with all your two week deadlines and your time boxes and whatnot, like I'll give you an example, I guess I should finish what I was saying, with your two week deadlines and your time boxes and your everything has to be known to be pointed or whatever things. that doesn't lend itself to being creative. that's what they'll say. And I'll give you an example just . To put a period at the end of this super long running sentence. I've worked on a number of teams where I've heard a developer say I don't know how long this is going to take, so I can't guarantee it'll be done in two weeks or they'll say we could deliver a vertical slice of functionality that's working, but that will not solve the user's entire problem. So what is the point of delivering a slice until the entire pie can be delivered to the user? What's the point of delivering a slice? There's no point in that so why put this like unnatural two week You know bookend on the functionality instead of just like taking as much time as it needs to, to deliver it. So this is the being creative and, and I mean, you could say like, you could, you could also say being creative in like exploratory tasks, you know what I mean? Like refactoring things or, or. Figuring out new technologies to work in that kind of stuff could go into this banner as well as like, well, you, they don't fit in two weeks. A lot of times when people say what, what's the point let's, when we can do, we have to actually deliver everything because there's still potentially shippable increment isn't usable in production. So why even release it, right? We'll just hang on to it and we'll release these five, six features together, whatever stories, whatever you may have where they're missing the point on this is. You need that feedback, right? So if you wait months and then get feedback, you'll have to pivot very hard as opposed to pivoting quickly for that little micro piece of the functionality. So that's actually very key yeah, but it's not ready. It doesn't have to be ready. Just show them where you're heading. They'll tell you if you're heading in the right direction or not. And so that's one of the things that I always use with teams Yeah, it's not ready. That's fine. Sometimes they'll say, well, we can't deploy it to stage because it needs these six other features to go with it. It's like, what would happen if you did deploy it without the other five or six, right? What would happen? It's not in production, right? Can you show it? Yeah, but it won't work for all of these other things. Great. But does it do what it's supposed to do? And can we get some feedback on it?. So I think that mindset of. Getting rapid feedback that needs to be instilled in these teams This is a great one that you'll also hear from , non developers, but in technical functions like data science and stuff like that. They'll say innovation may not happen through iteration? We may need to work on something for a long period of time , like delve into building a complicated data model or some, some, like a, like a deep refactor tasks if we're going to go refactor like I talked in the podcast before about going through a PHP, a five to seven upgrade or whatever, that upgrade took a really long time. Now, in the end we chunked it up by module and it's a bad example because I did iterate through that upgrade module by module basically. but we did hold on to all of the finished pieces all of the builds and demos that we did, we held onto those in a lower environment and we didn't push to a upper environment until all of them were done. But you know, the case that big leaps are not done iteratively. Which is kind of the case being made here like oh the big innovation It's done by just letting me go off in a corner and work forever. Like I don't know about that I think the big innovations come through Microdiscoveries and steering in the right direction. You may change and you may have lots of changes On the way in direction. But if you wait and don't get those , frequently, I don't know how often you're going to have those big lucky breaks, really. Yeah another thing that developers will talk about will be the interruption of the flow state , Oh, you need to give me time to be in flow or what they call it in social network, like wired in he's wired in don't, don't touch him. He's wired in don't disturb him. Okay I was just pointing out earlier, like sometimes we won't do daily standup because people know what they're working on and like everyone's got Slack, right? Slack is a asynchronous tool. So like if you got notifications and all that stuff turned on, like turn all that stuff off, you go check the channels when you are ready to check the channels. It's just like your email and your phone and everything else like do you you let all that stuff interrupt you every single time It beeps every single day all day I would guess you don't get anything done If you do sure i'm sure people have the notifications on they might hear a ding and they just like Have the self discipline not to check it, but yeah, I turn everything off because again like i'm a 90s kid So like I I learned that like you go check your email when you want to check your email Don't let it check you you've got mail How do you can I find that sound online? I'm sure you can. it's really just thinking about how you're working as a team rather than individuals, right? Because a bunch of individuals do not make a team. So what I'm trying to say is this, let's say you have six people on your team. Do you have a team of six people or do you have six teams of a person each, right? And I seen that, especially in strong teams that have strong personalities. Right. Well, people say, well I've been a developer for 15 years and I know what I'm doing. You give me what needs to be done. I'll give you the best quality work ever? Just leave me alone for 10 days. Yeah. I worry about those people. Well, I have to say, man, this is not the podcast of debunking any of these and I'm also not trying to, I'm not trying to come down harsh on any of these points. But I do have to say why so few developers have adopted XP? Like 20 plus years after XP was a thing. And they still resist working together because, because coding with somebody else is scary. To have somebody look at the code that you're writing over your shoulder, that's just scary. So people are insecure about it for the wrong reason. I make Python work, and I think the code is pretty fantastic for my own usage, you know what I mean? But it's scary, The point I'm trying to make here is why is there not more of that teaming that journeyman apprentice kind of master, master journeyman apprentice type of, you know what I mean? Like your journeyman can kind of do everything on their own, but you know, your apprentices need to peer with someone and then the master kind of helps. all people at all skill levels, like why there's not more of that? Why that particular movement did not become the standard, which is still not the standard today. The standard today is a junior developer who just figures it out and gets thrown into the fire and gets yelled at a bunch. You know that now, like in the next 10 years, Siri set a reminder for 10 years the next 10 years, it's going to be even worse. Cause everyone's going to be copying spaghetti code from ChatGPT. And Oh boy, we do need to move on, but I'll say this one last thing on why that model didn't take off. And that's because The barrier to entry became much lower for people. I thought you were gonna say because management hates you, that management does hate you, but, but, but the barrier to entry, went away from show us what you do now. It doesn't matter how bad it is, and we'll help you get better, right? Like, I'm thinking in my mind, the analogy with martial arts, when you go in, and you're nobody when you go in, you get beat up all the time, but they teach you, they teach you stances, they teach you how to roll, how to fall and roll, all of that stuff, and you get better over time, right? We don't have that today, because to come in, you don't need to show that initiative, all you need to show, Flash is some kind of certification says, Hey, I'm qualified. Developers don't have that problem though. they basically just don't need to show any, like the, I don't even know what they show. They show the latest languages and skills on their resume, but really you can't tell if they have it or not. That's not great. Well, I thought about something also while we were talking. can we add to the working agreement? Can we add a little star onto that and say, and Eric Schmidt, because that was Eric on the Eric Schmidt podcast. That was his view. He's like all these developers and they never do what I want. You know what I'm saying? Like, but I feel like the Eric Schmidts of the world will be like two developers in one chair who would nobody can live at that speed. It's not efficient. Yeah. I'm not going to squeeze my get me somebody from India. Right. And then we'll get them to work Saturdays. That's the latest thing to work 120 hours. Yeah. So the other thing if anybody to put a, to put a cap on this category, because we rambled too long scrum should be the thing that creative teams, like if you're scrum. If your scrum was a three day scrum and you had no backlog, you just pick the top item up, work for actually, if your scrum didn't have a time box, you had a time box of however long the top item did, I'm describing Kanban seriously, this one do it and you said, I'm going to work on the top thing when I'm done, I trigger a sprint demo, I'm going to demo to the user, get the user on phone, knock it out and then boom, I go right into the next planning, pick up the next thing that's Kanban, right? Like a lot of these things would go away. You wouldn't claim that, Oh, I'm not, I can't, can't be creative and use this. You absolutely can be used to scrum and be creative at the same time and eat all your cake and pizza at 7am you're absolutely right. But most development teams that say they're doing Kanban are actually doing Kanban they're doing Andon. So they're not really. Doing things like respecting WIP. So we keep starting, right? We don't finish. But if you are truly doing that, as you mentioned, establishing a flow where it's a pull system, right? You pull the highest priority item, you work on it and push it off to the right, pull the next one, but as soon as that item is finished, get feedback, do a demo right away. There's not a designated demo day, right? As there is in Scrum. If you're truly doing that, You're doing the best you can to satisfy the customer. The other thing that I will point out right before I move out of this category, we did a whole podcast on the term MVP, and I feel that a lot of developers saying that scrum can't be used for creative work or agile, whatever doesn't lend itself to creativity in the development process or through the development process. I would expect that part of the watering down or co opting of the term MVP plays into this meaning. And also with the product operating model I see that we're going to probably drift even further. if you go back and you read the Eric Reese lean startup terminology for MVP, or go listen to our podcasts on MVP, MVP is just the smallest amount you can do to validate an idea against the market, whether it's good or not, and your development team should be the ones doing that validation. So is it development team plus product manager? Is it the designer plus the development team is a designer. It doesn't matter. Your development team should be involved in those experiments that are happening. This is why the double diamond, the discovery delivery diamond that drives me insane every time I see it. Because it seems like an end to end process where certain people pick it up or whatever, and I'm sure that's what most people see it, and their mode one thinking brain is like, oh, I had my designer, the step one, and I had my developers, the step two, that's not what it's supposed to be. So if you're saying, Oh, the creative works not put on my plate. They just hand the code at me and they say, go monkey code this First of all, keep their resume updated because you've been cut out of all the fun work. You're not the fun stuff developer. You're the drudgery trying to fix somebody else's code all the time. And also if you're in that position,, you're the people that the Eric Schmidt of the world is trying to put out of business. Spending billions and billions of dollars on ChatGPT that's not what development's supposed to be. That's not what product management supposed to be You're all supposed to do this mvp testing an idea an idea could be If we tweak some widget or format or something on the website, then people will find it easy to use but an idea could be A whole new idea for an app stands something up. Most developers' MVP experience is put out some crappy code that falls over as soon as it gets a load or as soon as it a bug hits or something like that. a path through the code that we didn't expect gets hit. And then the, then the everything fails and the developers gotta get up in the middle of the night. That is not an MVP. Absolutely. That is garbage code. I'm laughing because most of the time when people say MVP, they hide behind the term when things fall apart and they just go, well it's MVP, right? No, because then they'll try and say, well, we get that. We didn't do that yet because we'll do it later or we'll fix it later and later. Doesn't never comes. Yeah. Or later goes to the bottom of the backlog, which eventually goes away. Exactly. Yeah. So you still have crap out there. Yeah. Yes, you do. this is not called MVP anymore because it's become part and parcel of the product and Lord help you. The moment that you start getting paid money for that crap, because that means it's permanent crap. Absolutely. Yeah. And then you're living in a house built on a foundation of crap. The crapification of product. Well we talked a lot about product management. I guess it's time to talk about product management for real if you're doing this, if you're doing this story point theater and you're doing this number of hours per story, or you're doing any kind of funkiness about estimation, if you're doing backflips to do estimation, you're living in this world. It's like, you're playing some politics, probably. About like you say it's a five and then your manager comes like, Ooh, a five reel. I had a manager one time who he would sit in sprint planning and no matter what anyone's estimate was, we estimated hours back then, this is years ago and whatever anyone was at, I think it'll take 12 hours to do that. And the development manager will go, Ooh, he would use that. He'd suck in the air and His voice would go real high. 12 hours of 12, no matter what you said, you could have been like, it'll take 15 minutes. He go, Ooh, 15 minutes. I had a simple response to that. Just don't know. Well, that's what the teams do. They weaponize it. But no, I would just say, well, how long do you think it should take? You know, so if you say 12, so I think it's more like four hours. Great. Done. We'll assign it to you for hours. It is. You own it, right? Oh, no. You're doing the work. If we're using scrum, the sprint planning should be a quick, Like here's, it should be the what and then how it should be like the, the, what, here's all of what I want to do. And then here's some points on it. If we haven't done, or here's some hours or just a wag estimate. Right. And then in detail work, we'll do all the detail work. So he'd be in the, what part of the meeting. When we're assigning an initial like even t shirt size small, medium, large, whatever Oh, that's a large. Really a large I think it's a small He's like, why do you think it's this? What do you got to do? No, you got to do this and then he would go immediately into like he transitioned to the solution. So I that story could be a different podcast You Point I'm trying to make with this one is getting beat down about estimates, no matter if they're story points or hours or t shirt sizes or really whatever else, or another reason that most developers are like, they have bad experiences with this. Sure. And that's what leads to overestimation and all of that, because they want to protect themselves too. You know, another thing we talked about is the business pressure, sometimes this comes from the product manager, Sometimes this comes from. Managers, you don't have a product manager, whatever. But we talked about just shoving more work into the sprint and not taking anything out. But we didn't talk about turning StoryPoint 8s into StoryPoint 3s by just putting out a bunch of code that you know is going to need to be refactored later , basically creating technical debt that's never going to get paid off. Right. Yeah, this is definitely fragile. As you're aware, the culture makes the team want to say, sure, that's a three point. Right we'll get it out there. It's crappy code. We'll fix it later. That's just terrible because later may never come. And it may never come for a very bad reason. That is the customer is so disappointed with what they see. They don't want you to fix anything. They're just leaving you that happens. a gripe that the developers rightfully will bring up is that like, for example whenever they point out stuff in a retro, like it's impossible to change things organizationally, basically the, the organization will not allow the teams To make changes outside of their team. I was in an organization once where it was like what book is this? I almost want to say it was who moved my cheese. It was too early for books, like extreme ownership and stuff like that, about like, there's always something you can do. You know what I mean? stop blaming other people for like things that you can't control. And just look to your team to do what you can control on your team. And I'm like, yeah, but the problems are not in our team. The problems are all these handoffs of the team, like the, the problems are all the processes. The intra team, inter inter team processes. It's all about the organizational construct and the teams have absolutely no say in that right. But at the same time. Every team that is delivering a solution jointly is being blamed for their individual portion. If you fix all of those things, it will still not be a success because the org structure isn't aligned the right way. see our podcast on Deming. Talk about the system, but this is, the illusion. I penned, when I wrote this one down, I wrote it down as the illusion of self organization. Self management. I don't know what they call it now in this format, but the idea that like your team really has no say in what they take in a sprint planning, no say in team composition, management to take people on and off your team whenever they want. Shuffle teams around whenever they want. no say in the work methods. the agile principle of your team should be in control of like the methods and processes and stuff like that. And if you don't have any of that stuff, you're not being agile at all. You've got this command and control going on. So like, if you're in command and control, no yeah, that's your problem. You need to find a non command and control place to work. companies who really force this way of working will say that's the best way under the guise of standardization because it makes it easy for them to gauge and assess teams, individuals even if everything's standardized? Unfortunately, then that leads very quickly to measuring teams across each other. They'll say, well, the PMO has to have standards so they can support you. The reality is they're actually your roadblocks right there. Because the team could figure out a way around the org structure. Ultimately, you really need to redesign the org, right? But again, the teams have no sway in this matter whatsoever. Not many people do. So org structure is real. The teams cannot get out of their own way. Individually as teams to deliver successfully because they're bound and hindered by the way the organization is structured. So org design is a big part of the equation here and it largely is ignored because people just say, well, I can't move city hall. I'm just going to do what I do. and the other thing that will intersect with this is if you read any developer forums about scrum masters. You will see almost a hundred percent negative interactions because the scrum masters they have on the teams and it's not surprising that they're in these command and control centric organizations who've hired scrum masters. I don't really know why these command and controls organizations. Have scrum masters in the first place. I do know It's because the pmi, stuff is not in vogue anymore The scrum master stuff's in vogue, but they need someone to be their eyes and ears Yes They're spies and a pmp certified project manager is just very expensive compared to a scrum master So we're gonna get one of these people and throw them on the team Yeah, there's a lot there. I mean a lot of companies are trying to save money. Onshore person, a PMP, who's been a project manager for a while, you tell them to be a scrum master. They find it hard to fulfill the duties of a scrum master because they've been successful as a project manager, largely following the command and control methodology. Here's your work breakdown structure, Brian. Get this done by next Thursday. They've never done the work, ever. They don't know if it can be even done by Thursday. They're telling you what to do, when to do it by. And then suddenly you're saying, well, we don't really project managers anymore because we're supposed to be agile, in double quotes. So we will just simply relabel these people as scrum masters. They're going to continue doing what they did before. The other part of it is they'll say, okay, these people are expensive, so we'll let them go. And for one of those people who we let go, we can get maybe two, potentially even three scrum masters from offshore. Lo and behold, you get scrum masters from offshore that are let's just say not very well mature in their craft. So these people are what I call textbook scrum masters. They will still follow the three questions. They will do all of those things by the book, they won't really protect the team. They won't really do the things they should be doing. So the contrasting side of it is interesting because I've just recently seen that work very well where the team actually says, We didn't like the old scrum master, but we like this new scrum master. And the reason is that scrum master is asking all the right questions. They're sharing the product roadmap with us. We didn't even know where that is. We don't know if we're going to be here a quarter from now, but now we can see on the roadmap, right? If we're going to be here or not, we can be a part of the discussion now. So I've seen. Teams turn around and say, this is great, and they get behind that scrum master. These scrum masters that are doing the textbook methodology. If they're late five minutes. The team just sits and waits, right? As opposed to the other scrum master who, well, after all, scrum masters are optional for the daily sync but if they don't show up, the team gets on with it. That shows that the scrum masters had a hand to play in instilling the culture of self organization, so that goes a long way towards getting the team on board. But then they get stuck at that whole org design obstacle right there. Well kind of the last point that we'll talk about and this one will be quick, I swear that I will hear is scrum slash agile. They'll say Agile doesn't handle any dependencies, anything that crosses team boundaries. It doesn't handle it. Yeah, so Chaos breaks out when anything has to cross teams all the marbles fall out of the bag and this is especially worse in regulated industries banks stuff like that or more old school type of industries where cross team dependencies are a normal thing. And people who make arguments about this stuff will hold Google up to be like, look, Google doesn't have whatever good, first of all, Google does have agile coaches. So a lot of people are just saying stuff because they think that Google does or doesn't without investigating, putting that to the side for a second. Cross team work from what I've heard from people that have worked at Google is a nightmare teams own little systems in order to figure out how to interact with all the systems you need to produce a functioning application at the end of it is an absolute nightmare with their web of software and to their web of interconnected software products to make matters worse in order to get promoted at Google, like taking something that is existing and just renaming it and putting in a different place and changing the UI slightly is like a well known Thing to get your, name and application in like the catalog, whatever it is that Google has, it like lets you know like, Oh, congratulations to this person. They came up with this new product. So like they'll say scrum doesn't handle dependencies well, and therefore is like not good, you know doing anything across teams. Is not handled well like everybody like scaling There's so many different scaling methodologies have cropped up to try to solve this problem And they all kind of miss the point a little bit and miss the mark a little bit Yeah, and they'll use that to kind of accuse I mean again It's just the fundamentals gone bad or not done. Let's stick to scrum because I already have an arguing point for this one with Agile, which is why is your organization so big in the first place that you didn't respond, you didn't respond to say like who, who can talk to each other on a regular basis. And if you can't, I need to separate hierarchy reporting structure, like the hiring structure, software structures, all that needs to be separated. If coordinating is so difficult Someone needs to fix that by like building a wall between the i'm not i'm not saying build silos with that 150 person dunbar number. Yeah, you need to say like this is about the max my system can be and Like the original, Jeffrey Bezos at Amazon. Sorry. I can't not do Jeffrey Bezos. Sorry, Curtis. Why he was like don't talk to other teams, have it talk to their APIs and they should be self documented and you should be, then it should be clear enough and if they're not clear, open a bug on the API that says you need to make on the documentation, the API says you need to make this more clear. And like, that would be the way. You know, and then if an API doesn't do what you need, now you've got a product manager to product manager problem, which is clearly like, it's just a stakeholder approaching so that there are ways to deal with this, where you segment the organization and you divide and you segment and divide and you'll say, Well Om!, doesn't that lead to a incomprehensible massive web of, or yeah, over time. Yeah, it does. It sure does. And let's say it's constantly being refactored as the, as an org design, right? Not a lot of organizations do this because it's hard. It's hard. It is hard. It requires commitment from up on high. And oftentimes they do not like change. They want this feeling of constancy, right? This is what we have. This is how we work. The reality on the ground is we need to change all that stuff up. We need to change the way we work. I'm glad that we're ending this podcast talking about management. We should be talking about leadership, but we're ending the podcast talking about management because if you work at a place where you have any of the problems that we outlined, go listen to our Deming podcast. And listen the whole thing trust me. It's two hours. Well spent of your life. Absolutely So yeah, because deming says only management can change the system and 90 94 of the problems in a workplace can be attributed to the system Yes, which only management can solve and only six percent To the people. That's a really good investment of your time. So go watch that podcast. And keep that resume updated and let us know down below what your thoughts are on this podcast, plus topics and suggestions for other podcasts and don't forget to like, and subscribe.