AA83 - Agile Doesn't Work Here

Listen, Om, we really want to do this agile thing, but , we tried it before and Agile doesn't work here. Agile doesn't work. Here is one of the most common things I hear from organizations that are struggling with Agile in some way, shape, or form, right? So that's the first thing is, oh yeah, welcome what are you, what are you saying? We should be doing Agile. Oh, no, no, no, that doesn't work here. We tried that, We tried that Agile thing here a couple of years ago. It doesn't work. When you dig deeper you find out that when they say it doesn't work there and you, and you ask the question well what have you actually done before just asking to find out and , it turns out that they, they say they've adopted some theoretical practices adoption of agile events. And they say it doesn't work for them. So for example, , the most common thing I hear is our teams are on two week sprints. We've been on two-week sprints for a while, not seeing any value out of that, right? We're not seeing these milestones met on our Gantt charts. We thought we might and we're not. So it doesn't work here that that's the most common thing we see. Mm-hmm. The other thing we see is, , the teams say that they are delivering every sprint exactly what they, what they commit to. Mm-hmm. and yet, The customers are not happy. The recipients of the products are not happy. Those are the two things that I see all the time when organizations say Agile doesn't work for us, so they must be really special because it, it doesn't work for them, but it works for a lot of people, by the way, including some of their competitors, it works for them just fine. They're in the same competitive arena that you are in and yet it works for them. Why doesn't it work for you? What's it mean when they say it doesn't work for them? Let's go there first You started with two scenarios, which is, I. I am on two week Experie Sprint and I see no benefit from it and my customers are not happy. Yeah. Two separate completely separate statements. Telling me that you have adopted agile practices and that your customers are not happy. I would definitely wanna dig into that first, because Agile in its purest form should be talk directly to the customer. The team is doing the work. Figure out what the customer wants, go off and do that for a couple days and come back to the customer and then adjust based on what the customer says about the work that you've done. When you say we're the customers are not happy, it makes me think that you're doing Agile, but you've put a firewall in between your teams and the customers. You're doing Agile, but the customers don't get to weigh in. But once every, I don't know, quarter, right? Once a year. When you have conferences, I'm ready to, to question to, to lightly question, lightly question gently problem with, with a white glove question your methods. so I just wanna go back to the first thing you said, which is the customers are not happy and, and are they seeing what they need to see every so often, right. Or are they only engaged once in a while? That's, it's one of the anti patterns I see as they say, Well the teams are doing good, but our products aren't really that polished and we really don't wanna expose our dirty laundry in front of the customers. Yeah. So we, they're not invited to our demos because we don't wanna demo this stuff. It's just not polished yet. Yeah. You know, and so they keep doing this stuff, sprinting, sprint out until at some point when the customer., what do you have for me?, I've been waiting patiently. Mm-hmm., they look at it and that's when they say, jeez, this isn't what we want. Mm-hmm., Right? Because many sprints have gone by. Now it's too late to quickly pivot. organizations that do that typically are the ones that are smarting from this whole experience and they say, Ah, I see we tried it, we tried agile. It doesn't work for us. You really, really tried. So I think that that line, you didn't really try to be agile is pervasive. Among everybody that I've come across that says Agile doesn't work here. They didn't. They say, Well, we tried it a year ago, two years ago, it didn't work for us. And I dig into it and say, What did you try? And they say, Well our teams are doing two week sprints. Well, who was really kind of feeding into your backlog? Who was looking after the customer's interest? I find there's huge gaps usually there. The customer's not even involved in this big picture. In many cases. In many cases it's internal people., just, just basically trying to make sure that their turf, if you will, is protected, right? And , you get this, it's not me. Right? It's not me. Cuz look, I've got a backlog. That's all I'm responsible for. Right? The dev teams go, Well, we're just popping off the top of the stack, right? For the backlog the poor customer says we're not seeing anything. And then the organization or the leadership says, We tried Agile. You really didn't try Agile. Yeah. And, and so don't say it doesn't work for you cuz you didn't do it, I don't see a way to talk about keeping the customer out of the conversation or not showing the customer our process while the, the, the tables all dirty cuz we got stuff all over the place and we haven't arranged things properly or whatever. Other than either ego or fear of not projecting that we have all of our business together and everything in the right places. You know, projecting that we are perfect and we got everything going, You know? So I don't know if those is the same thing or they're actually are different. I'm really not sure at this point but most of the places that I've been, that, that, that say, Wow you can't, you can't put these developers in front of the customer because they might they might not be able to give a polished performance and then they might even not be able to answer all their business questions. Well, where in the future. This is gonna be, or whatever. I'm like that. I mean, unless you're dealing with some kind of aliens or robots or whatever. Like, it's just people dealing with people. So the most, the best thing we could do is answer their questions honestly. And if we don't know, or, or if we haven't thought about something, just say that we don't know. We haven't thought about it. Right? On one hand, , I want to attribute it to people's egos. Like, especially when, Oh, they might make me look bad in front of a customer. Or the customer might not think the customer might communicate with somebody else in the company or whatever. And I'm afraid that I usually saying I meaning somebody in some sort of supervisory role, referred to as someone who maybe isn't projecting the vision or maybe the whose people don't really know what they're talking about or whatever, and then somehow reflect on me. So again, there is some sort of ego career move, ego consideration. Yeah that's behind this keep customers away from x, y, Z team or whatever. The other side of this is I have to think, ever since we did the podcast on the John Cutter's leading change, when Curtis was here, we did a podcast on leading change the book and one of the things he references in leading change is the vision, that is being pushed by the executives. It needs to be broadcasted out through every layer of the organization. Every time the executives bring up how the work ties back to the vision, they need to be quoting the vision. They need to be referencing the vision. They need to be talking about the vision. They need to be basically repeating the vision over and over and over and over again, so that everybody in a whole company is on the same page with that vision. So I wanna blame leadership and say part of it's just weak leadership with egos and people who really shouldn't be in that position. However, some of it is the strategy level that should be coming from executives. Just is not present and people truly are if, if different teams seem to be running at their own speed, it could be that, it could be, Hey, agile doesn't work here because agile, which normally should thrive in chaos, doesn't work because we change directions. So frequently or, or so much is, is, is in a state of change. Yeah yeah. That, it's the irony of that though, right? That's exactly why you need agile. Except we welcome changing requirements. The issue here is not changing requirements that benefit the customer. The issue here is that the management layer of the organization. Yeah. Constantly changing their mind and kind of battling between each other and, wasting a lot of time building the wrong things. Cuz they, cuz the, the viewpoint of the customer is not promoted as the first priority. I think that's right. And you know, I think sometimes, quite often in fact leadership are gunshy of failure. Right. The fear of fear of failure, so, They do communicate with the customer that we're gonna be agile. Mm-hmm., we're gonna be responsive to your needs. Right. And we'll be emergent, Okay, we'll do all of these things except they are not really sure how to do this. Because again, they, we've talked about this before. They didn't get into their positions by becoming agile. Right. They got into their positions over the years or by failing, following a plan. Right. And Exactly Right. Not failing and all of that. Right. Supposedly not failing. So when, when teams say, Hey, look, we need to pivot. And they go, No, no, no. I've already communicated X, y, Z to the customer. You can't pivot. Right? Right. So part of that is that inner inbuilt organizational inertia that kind of gets in the way of agile quote unquote working. The other part of it is, and this is I think significant as well, is the focus on the wrong things. Meaning that when they adopt agile, according to their own definition, however they're doing it. Oh yeah. The teams are now on two experience. Whatever they're doing the metrics that they use to assess whether that shift is working for them or not, it's often cast in this, this shroud of self-belief, right? Oh, if we just say the teams will increase the velocity in our agility is working, that kind of thing. So the focus is on that sort of thing. Mechanical metrics like increase velocity, increase speed of delivery, but are you delivering the right thing as opposed to just delivering things and, and not involving the customer's voice right up front. So show them something at the end and say, Is this what you want? and they say no, and they come back and the customer doesn't really know what they want. We thought they said yes to this, and now they're saying no. Guess what? We're not gonna involve them in future reviews. Mm-hmm., those sorts of things. Right so I, I think it kind of goes into various directions there when they say it doesn't work here. But the bottom line is they really didn't try to be agile in the sense of being agile. Responding to change, which means welcoming change, which means listening to customers which means involving customers throughout the process. All of that wasn't there. It was basically okay, we're gonna adopt some practices and therefore we must be agile. Yeah. Right. If you have a deep seated fear of failure, this is speaking as a product manager, right? If you have deep seated fear of failure, like may, product management is not the job for you, right?, for the people here that may, may have randomly found our podcast, if you are afraid of being told that your ideas are all terrible and that they won't work, and that you have to prove that they're going to work before you're allowed to do anything on your own and that is like too, too that yeah, that is too much for your fragile ego to deal like this is like, you need to get outta product development and find another job like this. It's not gonna work. It's just, yeah. it's a bad career field to be in because they, a lot of times you will come up with ideas that they, they are good ideas and you'll never have the ability to implement them because either the customer market isn't there, or the numbers aren't there, or the evidence isn't there. Or, or even like, this is, I feel this is the one that isn't talked about very often is the ability you have to expend to go get those numbers. the company's just not willing to even invest time in that. Right. Which stinks cuz then you don't even get a. solid A solid Oh, this was a good idea, but it, it, it doesn't work for our business. You don't even get that. You get, we don't have the money to invest in the time it takes to figure out if this is a good, you know? Yeah. So, if you're, afraid of failure, you, you are not likely to experiment. Right? Because you want certainty, that's what you want. And certainty only gets you one thing. It gets you a cul-de-sac. You're gonna go down a path and that's it. You hope your customer's there, but even if they're there, it's a cul-de-sac, you're not going any further. Right? So if you have that, that mentality of avoiding experimentation, you're stifling innovation, you're stifling the possibility of inventing things. Finding a better solution for your customer yeah, all of this is just, Pointing to one thing, agility doesn't work for you and it doesn't work for you because you want certainty. Those two things are kind of paradoxically opposed, Right? you want certainty, guess what? Don't do agile. Do you want certainty or do you want control? Because the difference is I think like power companies or telecoms, this is specifically in America. Cause I don't know about outside America, but the, like the, the phone companies or the cable companies or the, the internet providers, the ISPs in America the power utilities in America. Like, they're all basically monopolies in their area. So Sure. You want certainty, certainty is basically if you live in this geographical. And you want this particular service the certainty is you have the choice. You either get the service or you don't. Right. One provider that, that's it. That's monopoly. That's, Yeah. So, when I think about control, like the need for control, and I think about like the need to reduce uncertainty. Now we're going to our, and we're, we're borderline going into our podcasts on plans right now. So I don't know how, I don't know how deep we're gonna get on this subject. Well, we explore a little, but yeah. I don't know how deep we're gonna get on the subject because you have a whole nother podcast on this specific thing, but the fix that grinds against that need for control, that, that wears down, that need for control. I don't know It is to basically decentralize, it's to decouple things. Mm-hmm.. So, and then to, to basically scale your organization by not scaling, rather than scaling up and down, you scale sideways. Right. You get more product owners, you trust them to do the job that, that , in the area that they're assigned in the product or the products they're assigned to, whatever. but that inability to trust, which I label as you know, the need for control Great. Is some organizations that's, that is that inability to trust is pitched as a good thing. I think of organizations that I've been at that have a lot of, I think of the best project managers I've ever worked with. That inability to trust. Yeah. But as a, as. Professional skill. The best project managers that I've ever worked with, they don't let you, they don't let you slide on anything. If you, if, if there's something that needs to be done, they will say, Who is going to handle this deliverable? And then when somebody raises their hand, finally, after staring everyone down, cuz the best project managers, believe it or not, are okay with silence. They will let something linger. Sure. Like I, I've been, most, I would say probably the majority of project managers that I've been around they have to fill the silence. Yeah. With, with something but the best ones are comfortable with the silence and then they'll wait for someone to volunteer and then as soon as a person volunteers, Oh, I, I guess I can, I don't think that's a lot. I can deal. and then they won't ask, When can you have it back to me? By it, they will, they will pick a date outta the air and lay it on them and say, Well, since you said you can do this can you have it back to me?

30 PM Do you think you can have it back to me by the end of today? Well, that's a generous question. Normally it's like, you need to have it back to me by this state and time. Right. And is there anything you see standing in your way and you are now thinking about this, thinking, Oh, do I know, let's say take stock. What risks do I No, you don't. Okay, good. You're on.. That's what typically happens. This is classic risk deference. You there, these people that do this are deferring the risk of failure from themselves to somebody else on the team. Sure. Which is really just horrible. Right, Right. And it, and it contributes absolutely to this whole idea of actually doesn't work here. Well no, it doesn't work there. Well, once you let's say that you do that professionally. Let's say that you do, like you, you're a professional risker risk, risk delegator. You delegate risks to other people, and then when the risks end up being satisfied and then turn out where there are no risk, then you are champion. But if the risks fall through and become full blown catastrophes, then the person who failed is on the hook for like this . That's right. You've just described project management. It's so slick. Like this is so slick if you're, But I brought this up to say the, the, the culture where control is, the main goal of the business that we, we feel that we're in control of everything, right? Yeah. There would be culturally an inability to trust culturally because you've got people like that in the organization. Yeah. This is, Yeah. So yeah, this is classic old, old school, old style project management where a project manager would look at something as a piece of work, break it down and say, This is what needs to happen. And assign it to an individual and say, Here's your work breakdown package. Mm-hmm., that's what, that's what it was called. That's a real term in project management, wbs work breakdown structure. Yeah. So you have a structure that, that basically says, here are the individuals that are assigned this lot of work and, and the project manager, I don't know why, what makes them qualified for this, but they would decide how much work, the type of work, et cetera, each individual is doing. And again, I just go back to that term risk. Deference, they're deferring the risk from themselves cuz they had a project manager to the doers of work. So these doers can do perfectly well with everything, but it comes down to the pros and the proficiency of the project manager to say, this is the right work to do, the right people to do the work, the right time to do the work, et cetera. Right. And typically that's not been the case in my experience, because these people are not ones that have actually done the work themselves. They don't understand what it takes to do the work. Yeah. They are a manager of basically a project plan and you know, the one question they ask every day is, is it done yet? Yeah. That's the organization that supposedly adopts agility and says Agile doesn't work here. Right. Because that's the ingrained culture you have. Yeah. Right. Yeah. With, with a culture like that, I am not even sure where you would start yeah it's made even worse if all your employee, like of all your individual developers, like team members, what we think of as team members, we're all, are all contractors and the project managers are permanent employees. The levels. It makes it so insurmountable at that point. Right yeah. I I, I don't even know where I would start for, for people listening and I'm trying not to leave people listening to this podcast and complete despair. So we've, so far, we just talked about why Agile doesn't work here. Mm-hmm.. And we can kind of go to some of the reasons which you've already started doing so what do you do about that? Mm-hmm., right? That, that's the next thing, I guess, for those people listening, wondering, where are these two guys going with this stuff? What do you do about that? Right? First things first is recognize that it's not agile. That's not working, you're not really doing anything agile. You're simply putting labels on it, right? Look at your Scrum Masters, your newly branded, newly minted Scrum masters. Are your project managers that have just been given a new title your product owners, do they have a clue about product ownership or are they just people that were there in the organization that were just told, Hey, guess what, Mary, Fred, Joe, you're now a product owner. Yeah. You're not gonna succeed by doing that, so look at those kinds of things and say, really, We're not agile, we're not doing anything agile so that we cannot expect success if you're in that situation where Agile doesn't work there in your organization, how do you go forward from there? You know, after you've got enough gumption built in to say to your leadership, whatever it is we're doing, it's not working, it isn't agile. So let's do a couple of small things that are agile, right? Let's get the customer involved and listen to them. Really listen, let's get the teams to say what they can deliver towards what the customer's saying in a given period of time, and get early feedback early and constant feedback if you do those things, You're well on your way. Because you're gonna find in the longer term, medium, actually medium to longer term. Mm-hmm., you are successful compared to what you're doing today and claiming that it's agile and you're not being successful. The battle though, you're gonna have, I have to say, is not with your teams. It is probably also not with your customers. The battle you're gonna have, the challenges you face will be with your senior -to- executive leadership, because those people have the fixed mindset of how work is done in the, the command and control. Right. CNC environment. You need to break those shackles. And that is easier said than done. This is where you need somebody to come in and say, I've been telling the same things to our leaders, but when somebody from outside comes in and says exactly the same thing, it may have a shot at being successful because now it's from another source from outside the organization. Right? Yeah a supposedly perceived expert. Let's talk about that one, because that's a, where people either start their agile journey or they their agile journey gets reinvigorated or gain steam or gains Momentum is sponsorship. Usually what I hear is, Well, we have this person and the executive team, or we just the company just hired this CIO or c, xo, whatever whatever it is. Yeah. And they came from a company that used Agile, and now they're here and they think it's important. So they're they made a case, they, they're bringing in product owners, they're bringing the Scrum masters, maybe they're bringing in agile coaches so there is a sponsor on at the C level, right? Who's sponsoring the whole Agile initiative at the company. The other thing I've heard is we had these great processes and the company really believed in it. And then when this person from the C level left, everything went downhill. Yeah. But the ones that have been most successful obviously have been both. Yeah. Bottom down, sponsored while at the same time a strong initiative from the bottom up. So meet them in the middle type of deal. And the only people in there that are squeezed, are the middle managers who are Hey no, that's a real dilemma with the middle managers because again, just like senior leaders, middle managers got to where they are from the old ways of working. Mm-hmm. But we can help, we can help with that. We can help redefine their roles. We can help them by defining the roles that are different now for, for middle managers than before. so they're no longer commanding control. They're no, they're no longer. You know, asking the team or demanding of the team why something isn't done based on some arbitrary timeline to pivoting toward enabling the teams, making sure they have the right skill sets, right to do their jobs. So manage the, the team in terms of. Requirements, right? For skills, for example making sure that they have what they need in terms of resources, systems, et cetera, et cetera they're enablers in that sense. They no longer quote unquote managers. They, you're not managing anything at that stage. The team is managing themselves, but you are an enabler. You're really making sure that they the team has everything they need in order to succeed. Yeah, huge shift. Easier to say in a few seconds but mind shift out of a lot of transformations and, and even the cases I just outlined where I kind of left them out of it this is, this is probably pretty easy to take into consideration. The, the middle manager, if you actually, if you train the middle manager, As if you were training, like get 'em all together. Right. I I I I'm also making some assumptions that your company's not massive at this point, cuz of your company's tens of thousands of employees. Like, okay, maybe , maybe that's not gonna work. But also what do you transforming in an agile transformation? 10 thou, let, let's say you have a thousand people in your company. Mm-hmm., I'm gonna go big on this one. What, what if, what if you have a thousand people in your company? How many middle managers do you have in a company? You have 1,200, Let's say 200 at the most. Right? Okay. Well out of that 200 how many are in the segment of the organization that's going agile right now? Right. Okay. Maybe 10%. So 2020 middle managers. Yeah. Okay. Well maybe we can take those 20 middle managers, break 'em into two segments, have two teams at 10. Maybe we can make them enabler teams that unblock and accelerate other teams and now they have a new job purpose. But if we don't train them, On what their new role is now that we've quote, taken all their employees away. Yeah. Taken all their resources away. Right? Right. If we don't train them on what their new job is of course all they're gonna do full time is fight the process. Sure. You know, of course that's what they're gonna do, because they're not, they're being left out of the vision. They're not being given new tools to succeed that I, I'm expecting that these people are still left in those positions because they're they, they've proven themselves to the company. They they have, maybe they have leadership skills, stuff like that. Yeah., they're successful as employees probably is good part of probably why they're there. Yeah so like you're in a typical agile transformation that I think of I've been trying not to use the word agile transformation in this podcast. Right. A typical transformation these people are left out because the transformation has, has no place for these people, all the scaling models I can think of, ha ha have no place for these people. Yeah, I think you're right., I, I think from the perspective of those those middle managers, they feel like a loss of control, a loss of worth, right. That you Right. Self worth. I mean, you had it right, the unwillingness to decentralize. I think you had it right. Like the part of the unwillingness to decentralize comes from you have this, the glue between the top of your organization Yeah. And the bottom of your organization. It's not really top and bottom, but you the, I guess the glue between upstream and your organization and downstreaming your organization. It doesn't, I'm not really making it. I know I turned it sideways. I'm not really banking a, but the grew between head and tails. Yeah. The, I know the between, Yeah, the glue between the pieces. Yeah and again, all your models do this e even when you go to csm even when you go to your introductory csm, they do this. Oh, you don't need all this middle managers. It's all waste lean thinking. It's all waste. I mean, well, I mean, let's stop for a second. Like, is it waste? Because from my perspective, when you start talking about scaling and put all these controls in and this overhead in place, like actually if we think about it for a second, if the middle management enabling teams were doing their job, you wouldn't need all that waste, right? Because we can just take the people we already have in the organization and just kind of teach 'em, hey, when stuff fall falls through the cracks, when communication just kind of falls through, fall through the cracks. Well you're talking to everyone because you get a view across teams cuz you're the enabling team now. Right? But also since you're probably still the traditional hiring managers and you probably still are doing reviews and stuff like that, you also get to have a deeper interaction with the individuals. So you, you're seeing both sides. So actually you kind of are. Perfectly placed to not let things fall through the cracks if the organization treats those folks that way. You know, because oftentimes what happens is they're being told, Well, so and so that used to work for you and so and so else, and so and so else. They're now not doing that. So the middle managers immediately feels saying, loss of control by thinking I don't have as many direct reports as I did before. Right. And that, that goes to another, I know we're gonna talk about this, this incentives thing, but that goes to a different factor right in, in their quote, their performance at their job. It shouldn't be defined by the number of direct reports they have. It should be defined really purely at the same level as everybody else on the team, or even at the same level as, as they are middle managers. And then, , Wait for it. Those, those of you that are listening, even the leadership people should be defined at the same scale. Meaning how are we delivering to our customers? That's it. Mm-hmm., nothing else. Mm-hmm., so when those managers that say, to me now only have 25 or 30 people, geez, what am I gonna do? Right. I'm actually being demoted here. I'm not, I'm not as valuable. I don't feel like I'm making forward progress in the organization because should I have more as I go up? That's, that thinking needs to be turned on its head and say, I need to let go. You used the word decentralization earlier. Need to let go, let trust people to get the job done and get out of their way. Yeah. But make sure that if there's anything you can do to help 'em, you're there for that. Yeah. Yeah. I mean This is not really meant as a statement on anything. Who wants to work for leadership where the, where they have the inability to trust, Right? I mean, we're talking about micromanagers at this point. Like Absolutely. If they're not micromanagers, they're, they have , this overbearing meth methods of control in place in the organization where they can't they can't let anything go or Where you're going is you're, you're going down the road of using incentives as a positive thing. Mm-hmm. to propel us through to agility, to, to, to, to further develop our agility. Yeah. Usually what I see is the company will talk the talk, They might even walk some of the steps in the walk. They might adjust developments. incentives to be more team focused. Yeah. But then the rest of the business you know, sales, marketing, the executives, hr, it's like they don't even know that those different pieces of the organization exist with regard to their incentives. The biggest, easiest one to spot here for me is sales, because they get judged on their ability to sell things, but sell things that is in our software versus sell things that are not in our software doesn't really matter as long as they close a deal. Right. And rightfully so. I will like, I don't know why I'm defending sales for a second the, the business will say like sales is the, they're the lifeblood of the organization. They're the, they're the I'd say that's wrong. I'll tell you why. That's, that's what, that's what you have a very, very healthy book of sales. Right. But if you're not delivering and your pipeline is blocked, then yeah. Your salespeople are booking orders all day long and they're collecting their commissions. How is that really helping the organization? I've. Been lucky enough to be part of one organization where I saw this change over a few years where sales would not get their commission on signing the contract. They would get a tiered set of like events for their commission. So yes, they'll get a little bit when they sign the order, that's fine. And then when the software is delivered in what they call drop software drops over time until go live. But that wouldn't be the final commission either. It would be go live plus, right? So the white glove period, whatever call it all of that, hypercare, all of that is done and dusted and that's when they get their last chunk of their commission. The whole point, why I'm saying this is because it makes the sales organization well list two points I wanna make here. One is it makes the sales organization vested in the process. And the second thing is they will not go out and promise the earth because. They know they won't get the commission if it doesn't get delivered. Yeah. So what it did in, in my experience, is it brought them closer to the delivery side of the house. Right. So they started saying, Well, come out on sales calls with us and make sure that when the customer says we want your software to do X, Y, Z, that it can do that. Or if it can't do that, let's be up front and say we have to make custom changes. Yeah. What does that look like? Well, you have, you have to pay for some of these, Right? Or all of these. Yeah. Depending on what the organization's willing to where, where they're willing to meet the customer. That was great because the customer knows going into it before they sign the contract mm-hmm. what they're gonna get. Right. And the salesperson knows that. The delivery organization knows that. So I think that was a very good compromise situation right there. Mm-hmm., it worked really well the downside of it was back in the day. You know, sales jobs were prolific. I mean, the lots and lots they would say, I'm not gonna be here long enough to see the rest of my commission. Right. Why don't I get everything now? And we're like, That's exactly why not, because you're gonna promise the earth sure that we can't deliver. You'll collect your money and go. Right. So, yeah. So those are the two points I wanna make about this, this, this particular topic. Well, this, that's exactly the same reason why in, in the working backwards Amazon book, like the executive incentives, like none of them are short term. None of the executive incentives are short term. They're all in company stock, which is realize over a longer term, I mean, I guess you can get companies stock and sell it immediately or whatever, but I mean why would you do that? Right. You never vested that at that point either. I mean, like any stock, any stock you wouldn't do that with because it's stock you know that time and market is better than everything else. The reason I bring that up is I feel about the same thing I feel about the Amazon giving their executive stock the idea that it's long term you need to commit to the company long term. You, you're not just looking in, like this typical sales guy comes in and he is, six months I'm looking for another job. Right? Because like, why would I try to sell anything when yourself is I gotta sell it, but then I gotta kind of shepherd it through the adoption process and I gotta make sure that there's engagement and I gotta work with maybe a sales engineer or product people or whatever to make sure the software is easy to use, easy to start using, you know what I mean? To adopt at the customer. They're kind of invested in all that kind of stuff. Yeah. Yeah. The pushback on this one. It's, it's, It's very superficial in my opinion, but it is pushback is I can just jump to another company where they they gimme my incentive like as soon as the paper's signed, as soon as the ink is, while the ink is still wet, I'm getting paid. True, Very true. But you won't be there long because this is gonna be self-fulfilling. Right. So you won't be there long. Yeah. You'll move on. Nobody will be there long. Right. But you know, I think as we're talking about this, this incentives issue here, imagine for a second if the way the sales organizations incented, the salespeople are incented, was mirrored in the way your delivery people are incented as well. Yeah. Yeah. Right. So if you do that, what happens in the long run? I would be remiss in not mentioning this, what would happen in the long run., the customer is happy because the sales people didn't promise what could not be delivered. They stayed throughout the process with the customer. The delivery organization is happy because of what I just said. Mm-hmm., they didn't have to deliver what could not be delivered. Right, Right. So it was real, They could do it piecemeal, make sure that they're organized they're actually involved with the customer throughout. So they're learning about the needs. And inspecting. And adapting. Yeah. That's the agile angle here. Long term, what will happen is you will have loyalty from that customer. You'll have repeat business. Right. And you would have great references. Mm-hmm., that sounds all great and utopian and everything, but to your point, sales people do not wanna wait that long. Typically, they want, they want their commission now. They want I get it, but like, do you, do you wanna be part of something that's do you wanna be part of something big? Do you wanna build something big? If you have a happy customers, And you're getting great references. Aren't you now in the realm of the marketing department, but like, Hey, do you are, do you really enjoy using our software? Tell, tell me about how it helps you and then to sit down with them and get some testimonials. I think if you are lucky enough to really be solving real problems for a customer like now Yeah. I think your marketing department should be doing back flips and should be promoting that. Well, yeah. You know, like the sound of music. They should be singing it from ev from every corner of every hill. Yeah that, that people are doing a good job. But you know, how often have you, have you seen that though? You know, how often have you seen the hills are alive it's rare because of that short term versus long term thinking, Right? Yeah. Where short term always, nearly always trumps. Long I'm glad you went there cuz I wasn't gonna go there cuz I was like, Oh, the marketing people have even shorter tenure than the sales people. They do. They do. They do. I a lot of it, A lot of the times it might I'm positing again, it might be due to frustration because they kind of caught between the customer and the sales organization or the actual organization itself. Right, Right. Where they're saying, Hey, jump. Right, right now. Yeah. We have these these quotas to meet. Yeah. The incentives for the development teams? Usually the way that that lags is you are all of your, We talked about this on another podcast. Usually the way I've seen that, that lags is all of your developers have their one time yearly reviews, but then they go back to their, sitting on their Scrum team where they're just a member and they contribute to the sprint goals and they work on things together, and they maybe they're doing xp, maybe they're actually Yeah. It'd be different if they were judge measured as a team, but then they also got some sort of individual, I don't know , one-on-one type of counseling, kind of professional development focused type of stuff. But it's, it's not that. It's, it's, it's, they are a team, but then the team is never counseled. Right. I think the reward system is, is very individualistic. Right, to your point and, and some people have different clauses, I guess, right? For the reward mechanism. So so somebody might be told, Okay, this is your base salary, right? And then you have this 20% flex pay, which means if you really meet all your objectives, that we will decide if you meet 'em or not. Then you could get up to 20% of your salary. For example, I'm just using 20 as an example. Mm-hmm. And so then when you look at that, who is getting those versus who is not? I'm willing to say your, your dev team members, your developers, testers, et cetera, probably aren't. Yeah your architects or your, if you're at a progressive organization, maybe your tech leads, but usually it's, it's the managers that are getting those. Yeah. So if the development team delivers time and time again, then the managers get rewarded. There's definitely some sort of imbalance here. Yeah. That's, that's a problem, right? Yeah, exactly. Yeah. That's a problem. I'm also specifically thinking about it. Something that doesn't really fit in this, in this topic but I wanted to, I wanted to bring up anyway, which is if you don't have a, a resource manager, Right, Like a typical piece people manager. Yeah. If you don't have a people manager making the determination of what bonuses and what raises to give people at the end of every year. Like if, if we're truly doing incentives, team based. Right. And, and you somehow can figure out a way to delegate this to be up to the team to deal with. And this assumes also that you don't have , hiring managers that Matrix environment that kinda loans people out to, that that teams truly are like, instead of the matrix environment that where like resources or loan, I'm gonna loan you my stapler for a couple weeks. Yeah. Research it alone. Yeah. Copy paper stapler. Yeah. The people belong to teams and they, the groups the groupings, they're members of teams. They're not really like members of other, there's not other organizations going on. There might be other communities going on. The people voluntarily join, but people are employed at the company to be part of that team That is their specific purpose. Whereas a truly decentralized type of organization, large companies do this. Large companies have databases like they buy, pay, salary and pay information, stuff like that. And they have a a low point, a midpoint, high point for salary, stuff like that. I'm trying to envision in my head like something that an HR person could do on a team somehow would be you know, hey we've got this person on the team and they're low, mid, high point in the salary bands cuz assuming that the salary bands, maybe they're not hidden, but also maybe the company's not going outta their way to say like, this position makes exactly this much money. Like even if you just had the metric of low, mid high to the salary band, say, Hey, these people are in the software engineering salary. And along the software engineering, salary band, employee A, employee B, employee C, employee D, like A and B are both in the mid B is in the low and c is in the high. Yeah. And then when you come to some sort of like 360 review where people rate each other's performance I don't know how you would distribute salary salary uh bonuses, you know what I mean? That kind of stuff. I don't know how you'd distribute that to the team to let them do it themselves, but also because companies like we kind of talk about the need for control and stuff like that, like this, I feel when we cross this chasm, the very last thing that'll be hanging on by a rope, like down, hanging in the chasm somewhere will be the exact amount of money people make. Yeah. For working in a job role because companies are, companies will fight tooth and nail to, to, to not Yeah. To protect. Talk about the, to protect that. So if, is there a way you could. I don't know, some kind of mechanism you could say, Oh, this person's in the low band. Well maybe we should bring them at least up to the mid band or whatever. Like, I, I don't know. I think it can be done. I, I don't think this is rocket science, honestly. I, I think a lot of it is just inertia and old school thinking even among HR people, that that is slightly changing. I've seen some rays of hope there, but for the majority of organizations out there, it's to your point, yeah. Protect what someone is making, right. And, and leave it up to the individual to rise up. And, and that's why there's so much what's the word for this?, lack, I guess innovation, people wanting to better themselves because they don't, they don't know if this is gonna be worth it. Would I just not ride out my year or two years and then just change jobs cuz I can instantly go somewhere else and get a $30,000 raise? What's ironic about this, in my view, is the same HR organization that is not willing to invest in their own, people are willing to give others that they're bringing in a $30,000 raise. Right. That's insane. Yeah. Because you've got someone new coming in as opposed to someone who has domain knowledge who's vested in your company. So I, I think it can be done though to your point, but to do this, the essential thing that has to happen is to let go of that control of saying, we decide how much you make or you make. Yeah. It's leave it up to the teams, the 360 that you mentioned, let the teams look at each other and say, Look, how do we do? Yeah. And. What will come out of that is that those people that either are more senior just because of their depth of experience or those people that went the extra mile, right, Those people will be voted higher by their peers. And HR can easily come up with some sort of a scale that says based on how they're voted, is how we will peg their salary increase per per year or whatever it is. Right. Ideally though, what I would love to see is bring that customer in to that 360 and then make that decision on a project by project basis rather than on a yearly basis. Cuz sometimes you have bad times. Yeah and it's unfair to penalize people that are good intentioned, very hardworking people, and through no fault of their own things didn't work out for a project. So that would be interesting to, to see in real life you know, an organization going through that kind of exercise. Yeah. I could see you know, every sprint I could see measuring that you know, basically every sprint review measuring that or maybe it doesn't have to be tied with the sprint review event, but no, every, basically at the end of every iteration, taking that measurement. Yeah. So at the end of the year, assuming you're doing two sprints or whatever you've got 24, 26 measuring points, you have somewhere around 20 some measuring points per person, so you have a fair bit of data. Per person that you're HR can come away with. Yeah. And make their determination, your team even if everyone contributes their piece. And it's just kept separately for one person to make the determination. I, I feel at least then the one person that's making the determination is making the determination based off of some data as opposed to how I've seen it done, which is whoever quote owns all the quote resources. Yeah. Just decides who they like the best and who they who they want to quit and who they don't care if they quit. Absolutely agree. You know, I think the four, this sort of mechanism to work, one thing that is paramount is to keep team churn to a minimum because it isn't just the person who leaves, right. It, it is the fact that they left and now the team is back into forming, so it's gonna impact everybody. So again, that can be factored in by that. Person who is looking at this? Oh boy, we, we Oh, wow. What a huge hole in the topic that we were talking about. Like we completely forgot to talk about when management keeps shuffling your teams. Like that's a whole different podcast. But yeah. When like, Agile doesn't work here, but also we don't have teams that are committed to working on products. Oh, I know. We don't even have products. But if you're not willing to designate teams, meaning a group of individuals, there's a concept that I'm hearing now about fluid teams where people just flip over the place all the time., if you're not dedicated to having dedicated individuals who comprise a dedicated team working on a dedicated product or set of products, you're gonna have a big, big difficulty implementing Agile for the first. You know, like I could even be convinced that. Once you're doing that, Well, the, what I just said, dedicated people on teams that don't change. Knocking out products that are dedicated to those teams and no once you do that, then maybe you can start shifting people around and making your teams a bit more fluid over time. Once you've proven that you know how to do the, the first right set of things. Right. Cuz you would've matured by then. Yeah. Sadly though, what I see all the time is people that are shared across different teams, different projects unrelated often. Right. And then they're measured like, okay, how did you do against your, personal development plan or whatever, whatever the heck it is you cannot do that. Everybody has the row on that boat to. So if you're gonna put somebody in some of the role for part of their time and then say you, you're 10 hours here and 30 hours here. But in reality it's a lot less than that because of context switching and all that. Yeah. It just works kind of culture to what we're trying to do here. Five hours on project A, five hours on project B. Right. 10 hours on project C. Right., you add up all that and you're working over 130% and more. Yeah. Yeah. Yeah. But those are you those, But I, I can tell you in like in large organizations, those are your rockstar. Oh yeah, for sure. They have potential management, promotion, potential written all over them. They're willing to be your rockstar. Those, those are organizations that that reward having an over busy calendar as a good thing. 60 plus hours per week. Rock stars. Yeah. We've gone so far from Agile doesn't work here the last thing we have is concept of I'll, I'll, well, I'll let you, I'll let you deal with this one on because Oh, no, it's a great one. It's, it's the concept of being hoodwinked into adopting agile. Oh, yes. Agile doesn't work here because we were, we were tricked in the first place. That's right. Yeah. So again, this is something that I've seen way too often going into organizations and saying, Agile doesn't work here. So what did you try? Well, we were told if we do these. We'd be agile. And I look at that and go, Yeah, you were sold a bill goods there. So hoodwinked is a good, is a good phrase. You had somebody who was maybe you know, SPCT, SPC, whatever, It doesn't matter. It doesn't have to be that religion. Could be any religion. Someone who makes money, right? Who has a vested interest in the avenue. They're pointing you down and they come in and say, If you do this, thou shall be agile, and here's the real kicker. How long did they hang around? They don't stay with you shoulder to shoulder. They simply say, Do this. Trust me on this. I'm gonna train. Everybody in your organization, in the delivery side of things in this particular way of working and once I've done that, you're gonna be agile. You know, when they do that, they leave mm-hmm. because they've made their money, they make their money based on certifying people, et cetera. So this is what I mean by being hoodwinked. The other way I'd say people get hoodwinked into it is the product side of the house. People come in and say, Oh, you need this, you need this. And oftentimes they have the lingo. So the organization say, Oh, ah, he's credit, or she is credit, Right? They talk about domain based design. Wow, what is that? So they get. People in the room and they talk about the domain based design. At the end of the day, it isn't anything different. It's just cast the same thing in different language. And they say, if you're doing this, you're agile. And then they're gone. My whole point of both of these examples is these people that come in aren't staying with the organization long enough for them to actually start the turnaround process let alone actually mature down that path, they're long gone. Right. So that's what I mean. You've been sold a bill of goods. You've been hoodwinked into agility, and just because they came in, no matter how credible they're, you think you're agile now. Right? Because you paid a lot of money. And this is where it's a double edged sword for leadership too. Because if a leader brought in somebody and paid them a ton of money to come in and say, This is what we need to do.. Mm-hmm., and then they're gone. That leader doesn't wanna be the first one to say, Hey, look, I failed. I shouldn't have brought that person in. That's right. It's a sunk cost fallacy is actually what it is. But to me, it's a fixed mindset kicking pretty hard to say. Well, I can't, I can't admit failure on this one. I can't admit that I spent all this money to send my product people to product school or whatever I don't know. Product school, I don't know if there's a thing no, I know what you mean though. You know, I sent half of my developers at csm, two days csm, and then told them they can't talk to anybody leadership, and told 'em I wasn't gonna change any of the centralization of my organization. So they can't, basically can't do their job. And you know, now suddenly I, I gotta say, Hey, we're agile. I gotta try to sell that we are agile. You know, even though, all we've clearly done. Is a change from labels you know, change our project management office to program management office, but we're doing everything exactly the same. But, but you know, they brought in some big, big names. They brought in the likes of McKinzie or Bain that came in and said, Here's a model, here's a sevens model. And they, and they got ordained into this model, and then the consultants have gone. Yeah. Right. So now it's okay. It's time to implement. Oh, there's nobody there to help you with that. Right. But but we must be agile because we paid that organization, the consultants, a lot of money. Mm-hmm. And we cannot be seen as having failed as leaders. The reason I don't have great suggestions here is because my experience in this category was exactly what you just said. Some s SPC came in at a company I was at and the company was trying to figure out agile which was a bottom up approach. It wasn't really sponsored by anyone you know, C level or whatever. And the entire executive team was gone for what I swore was a whole week, but I, maybe it was two days. And I'm pretty sure they all came back with their safe, agile certifications. They all came back with their little placards and they're like, Look, we got placards. This is what we're gonna do now. We're gonna have trains and we're all gonna jump on the train, choo-choo! And we're gonna plan 12 weeks or whatever. No, it was 10 weeks.. But the one one week was like a, Yeah, the innovation sprint. Innovation sprint. Yeah. Yeah. But, but the innovation sprint was not the beginning. It was at the end but yeah, he's, Oh, our sprints are two weeks in length. We're gonna plan out five sprints and then having an innovation sprint after the, after the fifth for total of 12 weeks. And as a middle manager in the organization, where my team members were all part of different scrum teams. I remember f fighting a lot about like, this is ridiculous cuz we don't spend enough time in planning as it is. So you, whatever you plan the first sprint, like the second, third sprint is just gonna be doing all the rollover from the first sprint, right? And like, I have metrics to back it up but any pushback against this? Cuz again, the entire executive team went to the safe tra so people that normally don't interact with software development went to the safe training, the chief marketing officer, the chief revenue officer, the executive chief operations, they all went and they were told this is how your product portfolio works and this is how your development trains work. And this is this is the way it's done. So you, you plan your stuff and at the end of the train you get your release. So in the first sprint, we sat down in our big room planning to plan the, before the first sprint started. And it was an absolute train wreck, pun intended. And nothing in the first sprint was delivered. Because the leadership said like, Here are the things you're gonna do in the first sprint. Like they just dictated, Yeah, here the things you need to do. And then the first sprint was like, build an entire mobile app. It was just ridiculous things that you would never it was obvious to me at the time that it wasn't something that could be done but even if it could have been done in a sprint worth of work, it was putting a whole lot of development on one single developer. Build an Android mobile app. Okay, well one, the company has one Android mobile developer. So one Android mobile developer is gonna go off in a corner by himself for a whole sprint. And at the end of the sprint, he's gonna come out and he's gonna hold the tablets above his head. And here's what I produced. That, that's you Yeah. Ridiculous. Right? It is. But the idea was the executives were so unwilling to hear any detractors to their plan. we went back, we got this placard, we paid all this money, We know it's going to work. Go do this. By the way, Did not train anybody else in the company. Only the executives got trained and came back and said, We're gonna run a PI planning now and you guys are going to deliver in PIs. So think about this that was my first introduction to safe was somebody, some SPC or somebody came in and not only sold them on the training, you need to pay me x thousands of dollars for this training. But also they pitched these executives so well, they went back and tried to change the whole company to whole company mean just the development department because no other department of the company was changed by this., no other department was affected by this only development. again, if you're talking about getting hoodwinked, , this is probably a great example about like they felt since Hey, we pay good money to some consultant mm-hmm. and they said you guys should be able to plan this PI and be able to plan the next 12 weeks. And we told you what you need to do!, right. It was a disaster. It was a da, a bunch of people left. You know what I mean? It was a complete disaster. Yeah. But you know, the people that brought in the, the person who basically launched this whole concept of using safe, et cetera, and trained everybody, they're not the ones that would admit that they failed. Right. That that's the problem. That they're not gonna admit that. Because if they admit that, that's like, that's career suicide for them. Yeah. Yeah. So they won't do it. They'll just say, Well, we're gonna keep going. Right. So we've done this, we're gonna keep going. Oh no. We don't have all the prerequisites of how to make SAFe work. We don't have dedicated people in all these roles. What's an RTE? We don't have one of those. Yeah. Just find somebody with a pulse and go, You're an RTE now.. Right? And this poor person who gets nominated to be an RTE has no idea what it means. Yeah. Save a few Google searches. So guess what? It doesn't work. This is going back to our podcast topic. Agile doesn't work here. Well, guess what? It, it can't work there because you really didn't invest in it properly. Right? You are in that last example we've been talking about last few minutes. You are hoodwinked into it by those that have vested interests basically, you need to make sure that you bring in people that do not have that, people that are really looking at your problems specifically, and they're agnostic of a given framework, et cetera, a given approach, and the hardest message for you to swallow would be when they say, You're not ready yet for Agile anything. Forget SAFe, or whatever it is. You're not ready. You need to. Invest in these areas first.. , I long for the day when I deliver that message on my way out the door because Yeah, I was gonna say that it's the right thing to do. That would certainly be your way out the door, both from the client and from the consulting firm. Cause I can't think of a single consulting firm that would ever say Hey, Agile's not Right. For you in the current way the organization is shaped and operating, right? Like this is, we're not gonna take this contract. Like this is not it's not gonna be successful in the long run. Well, if you're a company and you're looking to hire somebody to do your software development for you or whatever, or to try to teach you how to , do agile , if you're trying to do that, I'd make sure that their incentives, their pay, their milestones, whatever it is, are tied to your success. Yeah. Your success. Yeah. Specifically your success with your customers and your success in terms of the efficiency and productivity of your development effort. After they have exerted their influence and their efforts onto your company Yeah. I'd say don't be vested in the next snazzy thing. Right. Just, just look for people that will really advise you with your interests at heart as opposed to their. Own interests at heart. Well, I think we've cracked the code. If we've helped you or not helped you please let us know. Let us know either way and let us know what else you'd like to hear about and subscribe and like that button down there.