Arguing Agile

AA226 - If Agile Really is Dead: What Agile Professionals Should Do Next

• Brian Orlando • Season 1 • Episode 226

Share episode

The agile brand may have become toxic, but your skills haven't lost value. 

If you're struggling - listen or watch as we discuss the valuable skills you have and how you might apply them in future roles. 

Founder & CEO Alex Polyakov returns to the podcast, joining Product Manager Brian Orlando and Enterprise Business Agility Consultant Om Patel for a discussion about the market shift that has taken place and how people avoid being held back by outdated terminology!

One immediately actionable piece of advice?

Reframe your experience in business terms, such as:
What impact did your presence bring?
How did you save money or drive revenue? 
How did you improve speed to market or decision-making? 
What deep organizational problems did you solve? 

These are executive-level skills that could translate to Director and VP roles. This work hasn't disappeared - it's evolved and so should your career positioning. 

#BusinessConsulting #Leadership #AgileIsDead

LINKS

Watch it on YouTube

YouTube https://www.youtube.com/@arguingagile
Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Website: http://arguingagile.com

INTRO MUSIC
Toronto Is My Beat
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Alex, it's been a while. Answer. Intro. Great intro. in the planning for this episode, we were talking about all this agile is dead stuff. And again, all three of us have unique and different perspectives on agile is dead whatever happened, happened with Agile. I would like to talk to y'all about if Agile really is dead, like what happens next? What do we all do? And second of all I'm seeing this thing on social media where people in agile coach positions Scrum masters , I'm not talking about the people that are cheating their job role to product management. So I'm talking about everybody else. Like they're outta work for a while and it bothers me 'cause they feel like being outta work for a while feels like it's like a reflection of your self worth. And I really want to talk about that in the whole podcast. Well, my, my, my take on it is we gotta stop talking about Agile. The ship has sailed, the work's still there, but as far as people are concerned there's one common language. And all of the folks that were in the Agile have been working in the business. So I think the biggest mistakes right now for anybody in this career is to see yourself as the part of the agile ecosystem. It is no longer the agile ecosystem. It is a business. And so what you have to realize is in the end of the day, you are a business consultant. Now you could specialize in different areas. There's executions, there's teamwork, there is a team topologies psychology, there's mental aspects, there's product. So there's a lot of facets. How teams operate, how companies function. But, everybody that was in the agile space had been somehow involved with the business. Business consultants are always in need in different capacities. So I think the biggest problem in finding a job is that. There are certain terminology that is no longer being picked up right by whatever the recruiting engines apply. And so folks find it very hard to find their position of yesterday. You gotta figure out what is it that you are doing? What is it that you want to do? And look for opportunities to do that with a different terminology. Lemme ask you a question. You think agile being dead, if it is dead it's just a passing fad, or you think it's, it's gone. Gone and whatever comes will be the new thing, the new shiny thing. If it's not here already, what that might look like? Do you want to get in on that first?'cause I have ideas too. Oh, I think the terminology's gone. I think we gotta drop the terminology. It's giving everybody indigestion. It's over usage. It's commercialization. It's young people, it's the generational shift. Young folks don't want to hear about Agile. Right. And so we end up focusing about structure more, but it's no longer the problem. Agile was a structured solution to problems 20 years ago, but the problems have shifted with the structure. New things emerged and we're doing things faster. And so we need the solutions for today. How do we get developers to work fast? You know, how do we get to work on the right things? If we are bringing additional tools and AI is a tool. What does that look like? You know who does the planning? How do we do the planning? How do we get the approvals? How do we get all of that? All of these same problems will remain, but we're no longer confound to a, a agile structure as a solution, as sort of your blueprint of how to get there. I wanna deep dive a little more on something very adjacent to that which is what are the skill sets then that are needed to take us to the next level, right? But before that you said you had some thoughts to share on that. That's all right. I forgot what all the thoughts were. I was a thought leader. Sorry. A thought leader. If I was gonna seek to tie up what we're talking about now, I would say all of these folks working. In the quote agile positions. I'm really mainly talking about people working in Scrum. That's really what I'm talking about right now. Product has kind of an easy out 'cause you can jump to product management, Marty Cagan writing books. That stuff's the new hotness at, at least it is for right now. Like a, actually I would argue that's on the decline as well. So like the, the like the whatever just happened. Tolis, I would argue that the product people as well, like their, their field has become so broad that like the, where that meme with like the green Reaper going door to door, like product people are immediately after the Agile people. And in fact, you see the AI people segmenting this market as well. It's all marketing. That's my, that's basically my diatribe. That's where it's going. This is all marketing. The, the product people, the grim Reapers coming from them next because product people like. We don't really know what their role is in the business, in the worst businesses, they're just feature managers and we don't need, there's no value in that at all. And the people that are not truly empowered with driving business outcomes empowered with driving business, they have budgets and the decision making power and the actually, and autonomy actually autonomously empowered Yeah. To do what they're supposed to do. I would argue that , they're next and because of, so many people like that all of product management is gonna get labeled with that label. And is gonna be the next one that is viewed like Agiles are viewed right now, is well, I don't understand what they do all day. What does a scrum master do all day outside of 15 minutes after they run like the stand up? Yeah. I think it's a little bit different. If a scrum master is taking care of the team right. And helps them execute and coordinates that or running interference and all of those things that are on the scrum guide, all of that work is invisible at the executive level. The product manager's job is visible at the executive level, especially if it's an important product. Because you take a slice above the execution and it's revenue, users, customer service, churn, all of those things that are bubbled up to the. Senior level. So you do see that result. Now you may not care what that product manager's doing day to day. As long as those numbers are positive. But I guarantee you that you will care what happens day to day if those numbers are negative. So that position will get exposure. Now, there is a problem where with the ai, the expectation is that the product manager's not just gonna run quote unquote business, but will also be the coder and the designer. Right. And a million other things called, that's called product engineering. Now that's what the role is morphing into. Yeah, that's right. The work will never disappear. It shifts. Somebody's gonna have to do it. Now who's gonna do it? Is it more responsibility on the engineer? Are we getting rid of our product designers? Mm-hmm. Because now product manager can do Figma. You know, so I, I think those things are questionable. Maybe you'll be lucky enough to find somebody that's a jack of all trades, but usually it's followed with a master of none. Do you need that person or do you need somebody that's super duper specialized? I kinda see some parallelism here between what happened with Scrum Masters and. Traditional agileists, right? Like agile coaches and whatnot. I can see easily that happening with product owners and product managers. And that's for the same fundamental reason, which is if you have a pulse, you can just take a two day class and declare yourself a certified X, Y, Z, right? Sure. That of course, it happened a lot with Scrum masters, but I'd say it's even happening with product owners too. You're interested in product, right? So the first thing you do is you take a class and then you come out and say, I'm now a certified scrum product owner, or whatever the other one is. Sure. So experience is what's missing here, being able to really do the right things when, when called on. You know, same thing, same thing's gonna happen, I think with product. So Alex, what you pointed this out very early in this, discussion point is you do have a lot of people. Introduce into the field new. Basically, they, they've never, never done the job before with a potentially a two day class. Like I'm not, I don't really wanna harp on the certification industry that, that I, I do wanna harp on them, but this is not the podcast for it. Okay. We had several podcasts. We had one with Brent- is this industry fixable? And I think that was before episode a hundred. I don't remember how long ago? That's, that tells you how long we've been tracking this thing out of the corner of our eye. But yes, the industrial complex produced a lot of these quote coaches who, if Alex, you're saying what really are they, they're business consultants. You have this mill that's stamping new business consultants. But they they don't have a proven track record in business. When you or I think about, well, 'cause we've talked about this on the podcast before. The way I think about a scrum master, like they need to be able to, to, to make contact with people all over the business quickly. They need to be able to ingratiate themselves at the highest levels, C-suite, director level, whatever, depends on how big the organization is because we rely on those people to bring visibility to the big issues, to the people that can help make the change and then bring those people on board to make the change that we need. Because like the developers on the team are look, I just wanna code and do cool stuff. because the organization is set up as clunky as it is and because like we got all these integration points and whatever we, our day-to-day doesn't interface with the right people. A million reasons why we're not successful, but you got this one person saying Hey guys, I see you're having a problem. I'm gonna go get this other person. I happen to know them. I'm gonna call the bat phone. I'm gonna get Batman on the line. He's gonna drop into our daily scrum or whatever, and we're gonna solve it today because I got the right contact at the right time. This is like the job of sales is what I'm describing right now. It's like you have an internal person who just knows the right person to call at the right time to help get through the problem. I'm not saying they have to solve the problem, but, the reason I want to have this podcast was again, you have people that came out through the certification mill and businesses can't tell the difference between that person with the two day certification and the person with like five years of experience who actually knows about lean management and organizational design and, how software gets developed day to day understands the point of bringing the customer in for reviews and stuff like that, even though it's painful. And I don't know. Like I, there there's a, there's an agile bubble that's responsible for causing this negativity on the term, but I'm having a hard time pulling the two of them apart. Well, the, there's a little bit of a difference between new people joining in. Mm-hmm. You know, like young professionals coming through whatever program and the experienced folks not able to find jobs. The biggest problem that we have right now is the folks that have contributed for years and years are having trouble. Finding opportunities. Right. You know, and we don't have to talk about certification with 'em. You have real tangible proof and experience. The problem is that the way they frame their accomplishments and their achievements, they frame it in the agile terminology. Mm-hmm. And you need to decouple yourselves from something that's no longer popular. Have they worked in a business? Absolutely. How have they consulted the business to improve? And if you can formulate that way, then there is real value that you could bring to the organization. Now there are people, again, some people are better at product side, some people at the execution side. There's the business agility side, right. Which is more of a strategic side than there is the quality side. So you have to find the basis. However, I think there is a big discrepancy on which company they want to go and work in. Previously you would find small and mid-sized businesses with roles available to do that. Mm-hmm. Not anymore. Everybody's trying to be lean, so it's really only the enterprises. Yeah. And enterprises have been shedding, the management levels have been shedding, the project management have been shedding the agility Yeah. Aspects. And I would argue that money is there to hire. They just principally do not want to invest in that area. Om, I wanna pull you into this one because I, I, I, I thought about you. I immediately, when Alex started giving the bullet points here, I thought about, is this a. Academic theory versus like business practice type of like business experience. Or what is the ROI of having a coach? You know like hiring a part-time coach on a consultant. I'm thinking about this from a co consultant standpoint, are all these agile folks, do they all become business consultants and then if the market gets flooded with all these business consultants who have these specific skills that we're talking about, like let's pretend like everybody listens to this podcast right here. That's what I'm saying. Can subscribe. That's what I'm saying. If everyone listens to this podcast and I am valuable. How can people pivot their resumes and talk about their stories and engage with people to say Hey, this is the ROI. This is what I can do for your business in ROI, in terms of the organizational design and what I can do for your goal setting and all your apparatus of planning and all this stuff that's like that you're probably doing terribly right now. Have to admit. That's a fantastic question, first of all, and there isn't a simple answer to that. So let's unpack a little bit, right? People need help though. Yeah, they do need help. So here's the problem for just piggybacking of what Alex was saying. If you've just had a career in Agile, so to speak, right? It doesn't really matter what your role is product owner, scrum master or whatever it might be. And if you are continuing along those lines, looking for some work that basically just says, this is what I'm gonna do going forward, then yes, your resume is going to say. I've been an agile list. Right. Right. And no one wants to see that today. So they, that, that's a big gulf right there. Those people that are successful, what they manage to do is reframe it in a way that people can understand, not just about dressing it up in agile ease. It's putting it out there in simple, but business language. You either saved the organization money or you made them money. It's that simple or protect risk. Now how did you do that? How did you do that risk? Is that what you said? So the thing about Agileists that are trying to reform themselves. Ask those questions, start from there and say, how have I done this in the past for the companies that I've worked for? Mm-hmm. Forget about I took five teams and brought them to a different level of agility. Nobody cares about that anymore. Right? So if you reframe that, that's your past, bear down your resume. You don't need no seven page resumes anymore, right? One page, pair it down, get that business mindset, and then project forward and say, how can my skillset allow me to help a business? So think about it like this. Pick three different organizations at different sizes in different areas, if you like bus business domains and work out your plan of how you can position your skills to help that business either save money. Or make money and the resume wise as well. You know, take a look, history in your history, comments on the resume. And rephrase from what you did to what you've accomplished in business terms. Yeah. So it's not Hey, I've helped the team manage the backlog. Nobody cares. Everybody knows how to manage the backlog, but what did you achieve? How many deliveries were you able to push through? What did those deliveries do? What did those releases actually produce? Was that critical? Was that not critical? Did that actually make an impact to the organization? Yeah. A long time ago we did a series. We did a three podcast series and it was basically number one was the scrum master's responsibility to the team. Number two was the scrum master's responsibility to the product. And then number three was uh, to the organization. to the organization. And , it was very funny because the viewership of the series of the podcast was number one, the team, it was like high number two, the product was a little bit lower. And then the organization was like a third of the views of the first one. It was like pretty stark, pretty stark contrast that people aren't really engaged with like an org level type of discussions. Yeah. It's interesting org level type of discussions. Yeah. Yeah. It was interesting to me at the time, and it kind of also signaled, it signaled. What I see in that role is like pe when, when you start interfacing to be like, Hey, we can have a bit more efficient org that works together and helps. And like people are like, yeah, I don't, I don't care. There's no value in that. Well let, let, let, let's take a step back a little bit, right? So, okay. The reason why Agile is picking up all this flack is because the value is subjective, right? I think if we take a look at Scrum for example, having a scrum master or not having a scrum master, having scrum master role shared letting the tech lead just do the command and control model and implementation having a micromanager. And you compare all these models. I think the results are going to be almost identical, I don't think that either of those provide a superior result based or success factor than any other. So because there is such a multitude way of doing things and because the results are marginally identical, that's why people are looking at it and it's Hey, why do we have to commit to this structure? Like people can deliver software successfully without Agile or Scrum or you know, or create their own or do their own thing if it works. That that was the whole premise of Agile. If small increments and if whatever you do works, don't change it. Keep going with it, right? We don't have to call it Agile. Sure. And if you can still achieve that level of success, why do you actually need a structured disciplinary approach and higher specific roles? I reacted strongly to what you just said, Alex. So I want to talk about it for a second. That's a nice way of being I got hives. What you just outlined is a very compelling case. Hey, if we have a success in whatever we're using, what does it matter? I mean even in Marty Kagan's latest book in the Transform book, he's oh, these agile people can't they can't help you. Right? Yeah. Read my book, which is all an agile transformation book by the way. Sure. It's exactly what it is. The agileists, they understand team topologies, meaning like the, the book team topologies, like how actual, like good development teams work. When you segment by what the teams are doing, like the value stream teams and the component teams, they understand Conway's law. They understand why you get over a certain number of people and your organization just fails. Because Conway's law is kind of like grinding against everything. They understand. They understand when they're seeing symptoms of these things at work that action needs to be taken. And then we are saying, well, these agileists, they're actually like organizational architects and like that, that's not a term that's been coined anywhere before as like you have system architects or solution architects or whatever,. Organizational architects organization is broken up to position themselves to do the best work they can do. That's just not a thing. That's like sociology and whatever. And like corporate America doesn't, I mean, doesn't value that, but Brian, which agileists, I've met a ton of agileists and there are agileists that just show up and say, so what's your status? I, right. And unfortunately, most of the market is full of folks like that, where Scrum Masters an easy position to hide inside of a huge enterprise where you don't actually deliver the value. And I've seen Scrum Masters that just simply pass questions from one source to another. That don't solve anybody's problems. They don't run any interference that throw the team under the bus every chance they get. And it's that type of culture that is, okay. So unfortunately, for the ones that actually know about team topologies and actually care about changing organizations, that is a business consultant, right? Because that person has a much more depth than their own team. They know how organizations work. They've seen a lot of it. Explaining product management to them is not required. They've built product themselves. They know engineering. They know lies when they hear them. You know, it's a different type of professional. So let me ask you a question. Imagine you ran an enterprise and there was a person with this type of skillset. What title would you give them? Forget you, you have no agile titles available to that person. What title would you give them? What do you think? I give 'em the title that they have now, which is vp that's usually the, OR director. It depends on the size of the enterprise, but normally these people Bingo. Yeah, bingo. So, so normally, normally these people would get a title that is commensurate. Ooh, we haven't said that in a podcast. Oh, that's a nice word. Yeah. They normally, they'd get a title that's commensurate with the concept that they can run an entire business operation. Therefore they get a title that basically is like a catchall title that says you are a business leader. And that this is the main, one of the, like the reason that this podcast agenda stuck, there's several reasons. This podcast as an agenda, as a statement, emotionally, physically, oh, help me out. Like what? Psychologically, pathologically, I'm sociologically, like many reasons that this stuck out to me as like as a podcast that I really want to do is like people have convinced. The agile folks, and yeah, I'm you made a point that I don't I don't want it to go unanswered. Which is yeah, a lot. Like there's a lot of people that got the two day start and they really have not done this before and they're outta their depth. So yeah. Okay. I'm I agree with you there. Let's put them aside in a bucket in this for a second because at the end of the episode, I really do want to ask, and om you stayed in consulting much longer than I have. It's like the people that are outta their depth. Is that like 70% of people? 50% of people, like it's a large percentage. If it's a large percentage of the, maybe it's a problem and we need to talk about it separately, , if it's like 30% of people and they just get they get their first job and then they get washed out and they can't get back in their career field, maybe it's less of a problem. But if it's like 80% of the people out there and like businesses just can't tell the difference, then maybe it is a big problem. But the people that have the experience that can do the job, they are consultant business leaders. They know how development works. They know how to run experiments against the market. To figure out if customers really want features or not. And again well, what job title would you title those people with? I would, I would title 'em with well you can run a whole enterprise, so you must be a vp. And I just slap a VP or director title on 'em and be go figure out my, like what gets success kid? Go get it out there. So there are different types of VPs? Yeah. There are VPs that have entire departments built underneath of them. Yep. And there are VPs with just a few people and they have a very narrow focus in specific areas. Yeah. So this sounds like one of those VPs that has the ability to influence all others. Sure. Yes. Or directors. Yes. And you expect other directors to work with this director? Hopefully not in command and control model but in a collaborative fashion to help improve other departments in the way they operate. Does that sound familiar? Like 20 years ago before this whole agile thing? I completely agree. Sounds like it. I completely agree. If it's a business and we're hiring people and maybe I'm hiring someone with like a small sliver of staff. Maybe they only got two, three people under them, developer, designer, whatever. And my my thing is I'm gonna give this VP go test this market. Go expand me in this market, whatever. I'm gonna give them a broad business goal. They have a budget, they have a team. They tick themselves. They go figure out how to do it, and they've got everything they need. When you convert all the job titles of quote, agile job titles, like everyone loses their mind is the main thing I'm trying to get across in this podcast is the people that have been trying to make it work as a agile coach with like two, three teams under them or whatever. You've been learning critical business skills that you could basically take and become a business leader in any other org. So don't just because you are submitting your resume to all these agile coach positions or whatever, and getting bounced by the random a TS position or HR people that don't even really know what an agile coach is, or they can't tell the difference. Between agile coach with X years experience and like a person that just got their C yesterday. Just because you're running into these barriers doesn't mean you do not have valuable skills. I would argue you're not leveraging those skills to the right audience in the right way. You've gotta open your mind, first of all, and say, just because I've been an agile coach or whatever, scrum master, fill in the gap. Because the situation is no longer the same as it was when you did that. Yeah. And it might be just two years ago, or it might be 15 years ago. It doesn't matter. Right. So it's having that business orientation and, and not a lot of people can just switch like that. If you're a scrum master with three years experience, all you know is how to work with teams. You can't see yourself above that. Right. And that's a problem. And it's really kind of a disservice that the titles that somebody had historically, even though there's a big amount of experience have been only the agile titles, like how do you transpose it? Right? So for example, if I was in tech, I could be a senior dev, a tech lead, an architect, right? And at the end of the day, I'm still a dev, right? So I could still pursue that. But I think the biggest disservice that people make is devalue themselves. If they can't find a job now, they're oh, my skills aren't really needed. So they try to go a little lower, but without recognizing that the skills they possess are actually much more significant. Right. And instead of going lower and limiting yourself to the agile area, only reapply that as a business. Consultancy type of skillset. And you can go much higher in the organization. You have more depth than you can offer. And you just gotta get rid of the jargon and kind of edit the experience a little bit so that it's clear not from the agility perspective, but from the business value. I think it's hard though, for a lot of people to just get rid of those mental shackles. Of course.'cause that's what they've done. This is what when, when you, when you run into those kinds of people, you immediately know who they are because you ask 'em what do you do? And they'll go ba but I'm looking for work as what a ba. So it's hard to come out of that mold. Now, having said that, people that have been around the block a bit, they can do that. Those people will say listen, what I've been doing can easily be applied to project management, for example, or vice versa, which actually happened, right? A whole bunch of project managers got redubbed as scrum masters. Yeah. But so people can apply their background in different areas. Operations is another one, right? If you're a project manager, you have the, the skills to meticulously track things. Well, you can be successful in operations. There's no reason why you can't make it. You just have to get away from project management's all I've done and that's what I want to do. One of the hangups of Agiles is they're, they're stuck in this team level dynamic. Hmm. And it doesn't necessarily prepare them for the enterprise. Assuming that everyone wants to work in an enterprise level type of oh, I worked at 30,000 plus three, or if you're not working for like a global company with hundreds of thousands of people you know, you might feel overwhelmed or whatever. But yeah, you have like the organizational architect in disguise type of thing is still, it is stuck in the back of my mind from this conversation you coming from it from a systems thinking approach you know how to restructure the system to be more successful. So if you were to look at your resume again and revise it to show the impact on the organization. In order to look for a different role, like a director role or something like that. You know, like a people leader role.'cause that's what, I'm thinking about people that are stuck as a scrum master. They're outta work or stuck as an agile coach and they're outta work. And well what did you really do? The Agile coach and the agile coach slash Scrum master for Scrum masters, who manages multiple teams and the program manager, like those roles are very close together. They're very close together. I would say communications is probably the big leap you need to make organizationally. Yeah. Imagine you're in the interview and you've come out of a Scrum ecosystem. You elevate yourself to a business role and it's well, we'd like to improve the performance of the team. How would you do this? And that's the question you're faced. Well, you have to step away from the Agile thing and say, well let's see, what do you guys use now? Well, you're doing scrum wrong, right? Gotta step away from that. You have to understand a little bit more on business basis. Well, what would you like to improve? Is it the speed of deliveries? Why is that costing you what's things are taking too long. Yeah. Well, why do you think that is? Do you have any hues? Learn to ask more business specific questions without going too much into the weeds of execution. Folks that worked heavily in Scrum, they tend to jump a lot into, Hey, this is the way to do this. A model or process, this is rule book, this is what the guide says, and we have to implement the guide a hundred percent. And then you're sort of going right back into the weeds of where this system already rejected so you have to elevate yourself and just go, you know what, I'm gonna go a little higher. Yeah. What's our goals? How do we reach them? What stands in the way? What have we tried? But don't sink into the, kind of the agile jargon into that level. Now you can understand how teams operate and try to help 'em improve. But I would try to stay away from attempting to say, Hey, let's transform into Scrum. Let's do this implementation. You're doing this wrong. Yeah. You, we have to estimate by points or whatever else. Don't even go there. Try, try to bring in. Novel solutions into the business problem space instead of doing sort of the stamping of the scrum model. You're so right. I I could, I, I was just thinking about some of the, the questions you just outlined that could be asked in response to an interview question like that, and first reaction is, if you've been a Scrum master, the question you'd ask is, well, what kind of velocity do your teams have? Now I can improve that. It's no, don't think about that so much. Right. Go beyond that and say, well, what are some of the, the top two or three issues that we can talk about where I can really make a difference? Why are those top two or three? Right. What's the impact of not improving those? Right. Those, those are the types of questions you could ask, and none of those are at the agile level. They're all at the business level. Mm-hmm. Right. Just trying to understand those and see how you can how you can make a difference there. a lot of what you guys are talking about right now weaves itself in with lean management principles, which we haven't, I haven't brought up on this podcast, but I had it in the original show notes that I wanted to bring up is hey, you got all these people that have been trained on and read books on and understand the concepts of potentially, right? Like lean manufacturing and like they study lean. If you go all the way back to the Lean Startup, you know what I mean? They study and believe in the concepts of we'll just build the MVP to test an idea is good or not. And then we're not gonna engage the development team potentially the most expensive resources in the building unless we're sure that an idea is sound. So. We go from this mode of build it and they will come with the most highest paid persons in the room, opinion to this mode of everybody can put ideas into the pool. We grab the ideas and we test the ideas against the market. And then we only put the most expensive quote resources, sorry, I have to keep going. Resources for the people listening. I'm being super sassy with my ear bunny fingers over here and so that like the best ideas rise to the top basically. And they're the ones that get implemented. But that, that, that in order to move to a environment like that, even saying it, I'm wow, that, that's a, it's rarefied air up here that I'm breathing. Because like most organizations if you can get past the egos and all the stuff to even get to an environment where you're saying everybody puts their ideas into a pot and then we test the ideas. Then only the best ideas make it into the actual product that developers produce. Right. As soon as I hear that, immediately, the first thought in my mind is portfolio management and program management. Right back where we started with the old legacy enterprise attempting to do things at scale from multifaceted departments and organizations. Bringing that into the one priority queue and creating this community-based voting system of internal blah, blah, blah. Mm-hmm. And this is the stuff that we wanted to walk away from, right. And created sort of like the models of startups within the enterprise. And now we're right back to the, to the enterprise world of, hey, let's throw it all into one bucket and start voting. The funny thing about me, like trying to lobby for like lean manufacturing in this category is also I hear the other side of it in my head when I'm lobbying for it is like. Well, nobody getting like a two day certification is gonna understand anything about like lean manufacturing and what it really takes to consider the entire system rather than like just your team.'cause you can't just look at your team and how they plug in. You gotta look at the whole system 'cause you're, you're not optimizing for one team or another team. You're optimizing for the system. I used to have a CEO back way back in the day. When you optimize for one team, you de optimize for another. He would say it all the time. But now, much later in my career. You need to get your teams together or maybe reps from each team and kind of talk about what you're doing with the system overall. And that's the point of scaling your big sessions where you have reps from each team so you're not, you're not optimizing process for one team and de-optimizing for other people and kind of just moving the problem around inside of your inside of your manufacturing quote, manufacturing development. Look, some of the stuff you just talked about, which kinda. Knowing how to experiment, getting validation, getting the right signals from your customers before you build a solution for them, kind of flies in the face of, the new thing now, right? Which is build first. It's cheap, right? We build using ai, so build 50 things, maybe somebody will buy one of them. I just don't feel right to me, you know? Well, if you build that many things, you gotta find that many users and customers to test it. but these guys aren't testing. They're simply throwing things at a wall and hoping and see what sticks, what becomes more popular. Right. Essentially, it's almost like selling certain things to a few customers and seeing if they pay for it, but not actually waiting till it scales, right? And placing those bets so lightweight where I, I get it. You can test it out. But I think they're gonna get a lot of false signals because this is, wait, this is like two thousands development right here. This is the way it was back in like way back in the day. Oh, you mean the.com? Let's just build everything. Or the next one. Everything's an app. This is the way it was at the start of my career just build it because like anybody could just throw up a website and make a bajillion dollars or whatever, like a simple web app. That that didn't pan out for a lot of people. It did not. I think it's an enabler that made it happen. The catalyst here is ai, people can just come up with stuff that they can vibe code really fast. Mm-hmm. But that's not dollars and cents. No one's gonna pay for that. So their answer is just build more of it. Pay for something. I have another, I have a whole nother podcast, Alex, just to let you know, I have a whole other podcast, which is something along the lines of, speed through the development team; that was never the problem. I agree. If you really needed to prototype something, you got a couple, couple of really good guys or gals. And you just go to town and they, in a few weeks, they can give you whatever you need. You good enough to test and, and you know, if, if you had to have a roadmap for your prototype, something's wrong. Sure. Right. So usually it took just a few weeks and a couple, couple of really good people to put it together. I, I mean, I would argue if you don't need to support it or maintain it or whatever, like didn't a, a couple hours and you probably could have something up and running if you don't have to support it. Most development teams are not engaged that way. Om knows on the podcast, I'm a big, you build it, you own it. My team can maintain it and still have a nice work-life balance I don't create software that's gonna fall over all the time. You know what I mean? That's just a core belief. That's just a core principle that I have as a person that I got from working on development teams for many years and being up in the middle of the night and stuff like that, but if, if it's a greenfield and we don't have to maintain anything, we just turn it off at the end of the workday, turn the instance off. You know what I mean? That's a different type of development. It is. And it doesn't even have to be an actual app, right? It could just be a Figma markup. If you have the customer. So, yes. Let's take a moment to step back. Lots of startups. Yeah. Ton of startups. Ai, ubiquitous. How come there's not more success? You know what's missing, in this equation, the customer. Absolutely. So now the enterprise does what the startups are making. Same mistake, we build more, but who do you give it to? In reality, the enterprise model for building new things was always we understand that pain. We spoke to a lot of customers, we really know measuring against the competitor there is this market opportunity. What we will do is we will allocate the budget to build a quality product to go after that market. And we already have a couple early customers that are willing not only to try it, but to pay for it. Mm-hmm. And that used to be the basis for investment within the enterprise. Mm-hmm. Right? What, what's happening now? Oh, we got devs, let's just let, let them build stuff. But who's going to go ahead and implement who's going to apply? And remember. Customers, they're just like regular people. They get tired of being pitched too many things too often. Eventually they will get tired or they will start prioritizing what goes first. What goes second. Yeah. Their attention deficit is going to start increasing. And what will happen is over time nobody's gonna care that you can produce 3000 little minor niche apps. In the end of the day, they will want to comprehensive something that really addresses the bigger problem. And that will take time, time to build. No AI will be able to solve that right out of the box. Mm. Because we're only building niche solutions for small, specific little things. Complex software will not go away. Business problems are complicated. Right. Even AI won't be able to find the right solution because sometimes don't even, we can't. So and AI's it doesn't create anything new. It only copies on basis of what it knows. And those bets after they don't play out, what are you gonna do? You gonna place more bets? I mean, I've written more software that's sits on the shelf unused in my entire life. Software I was proud of, but never got used a hundred percent. And I'm sure this trend will continue. Because not everything that you build will be a product that will turn into something. Right. How does that make you feel when you create something that like you, it's great software and then like. It just doesn't get adoption.'cause a a million are different reasons, , it just doesn't get frustration, disappointment, super annoyed. It just shoots the mojo out of you. It sure does. If you are a passionate engineer and you love this stuff, like truly love this stuff. Mm-hmm. The number one gratification that somebody's using it. Yeah. Right. Is that there are people that value it and recognize you for doing a good job. Right. Even by name, Hey, I was involved in that project, I was involved in this project that's still used to this day. I mean, talk about the folks that built software for printers and you meet them nowadays they're retired and stuff and you talk to 'em. Oh yeah. I was on the Lexmark team and we built the firmware to print those very first blah, blah, blah, and they're fascinating people. And you respect them for that. I mean, like my mother is a COBAL programmer. She talks about things building on mainframes. Folks, folks don't really do a lot of development on that. I think that taking pride in something you had a hand in, absolutely. It, it goes even beyond software. One example is certain vehicle manufacturers, right? They will have the person who built the engine stamp their name on the engine. It's there in perpetuity. It's like the VIN number. You know, when they see a customer paying for that vehicle and say, I had a hand, I actually had a hand in that vehicle. Right? Yeah. I mean, that just swells, right? I mean, this is real. This is the intrinsic motivation that individuals have. I remember my first job as an intern I was part of a single point security it was sitting on VB script and I built reports, reports of organizational structure like departments and people and all that. I remember coding VB script along with JavaScript to produce like a pretty picture of a report. I was proud of that deeply. Like I would print it and, show it at home. Look, this is what I built the same feeling stays. And there's nothing more discouraging than software that you just crank out and does nothing. Yeah. But we live in a different world. If AI's building that stuff, do you have any kind of care for what it did? Not really. Yeah. Until maybe you made a couple million immediately by, by selling it. And then you are off to your next ideas. There are entrepreneurs out there that launched a hundred companies. None of them succeeded and they're still cranking out more. And they're big idea, man. But you know, in the end of the day, they're not swayed by any way that things failed. The lean principles can work. Like they, they're good and they really do work when allowed to work. Right. When not interfered with, that's the Deming. Deming calls it Meddling. Meddling, yeah. Or in the perfect environment, would you say? It doesn't even have to be perfect as it's an environment free of meddling constraints. Basically. Meddling means I mean, as an executive you really have a lot of control. In the prep for this podcast, I talked a lot about management coming in and saying oh, Brian we really love your team and everything you're doing is great for the organization, but we're gonna reduce your budget by X amount of dollars per month. And I'm that seems like a really specific number down to the number of cents. Why? Why is that? Why are you telling me that number? Oh, because we're removing this person from your team. It sounds like you don't care whether we're productive or not. You wanted to remove this person from our team?'cause it's, it is not like you're following up your decision with any kind of metrics to say we removed this person from Brian's team and therefore the team we put them on was productive or not. Because I would argue if Brian's team and the team you're removing the developer for from are equal importance and you remove somebody from Brian's team, move into this other team, and because you introduced a new person to the other team and because you took a person off of Brian's team, both teams now suffer for X number of months until they rebuild their ways of working, basically. You as an organizational planner first of all, they're not organizationally planning in this example, they're financial planning, there should be a metric that the person who made that financial decision. Should be held to, to say Hey, you made a financial decision to move money from this, this line item to this line item, and it affected these teams this way. Therefore get outta my office. There is no extrapolation. I know of the performance to your team. I know topology or set up, I know or number of people. We don't baseline those things. if we had the data, there would be a completely new revelation that meddling does impact things And in preparation for this podcast, we also talked about the impact of layoffs and how they're continuing. And I, I, I would argue that totally unnecessary. These companies are making money, they're cutting staff, but they have plenty of money. And as funny as it may sound, they're not even impacting the market share or shareholder value that much by trimming those resources. Mm-hmm. I question what motivations being driven? I doubt it's cutting low performers. I don't know. It's not really clear. Maybe one reason is like you said, they're making money, right? So. By cutting staff, you're directly impacting your bottom line, right? You're saving money by saving all those salaries, if you're not paying people's benefit and salaries, those are savings right away, but not immediately. So like a lot of companies, they would realize only those savings like a year or two after. Yeah. Because they can project that for our next quarterly report, financial report. We are doing fantastic because now, you know in their statement that they release, they can say our operating costs are lower. But that's short term financial. That's financial manipulation rather than actual value, which is what everybody's doing. Right. As soon as you threw this out as a conversation point, Alex, the first thing that came to my mind, and it really hasn't changed with your back and forth, is that's what everyone else is doing. It, it's a fomo. It's like everyone else is doing layoffs. Like if I'm Google and I'm looking around the market and it's like Meta is doing layoffs and whoever else is doing Amazon, whatever market Microsoft did, yeah. I don't want to be left out of this. I should also do layoffs. And also you have a little air cover. There's some games being played as well. The unfortunate side of it is at the end of the day, it isn't just. Numbers on spreadsheets. They're real human beings with families. Impacted by this. That would be the real issue. Yeah. The sacrificial pawns are real. You gotta get you gotta get over having a conscious home. That's what I'm asking. That's, I'm trying to tell you right now. I was born with one. It can open, it's a big problem. I wanna move us into the end of the podcast to ask the toxicity with the term agile. If agile really is dead, like if that's really where we're going here can the brand be saved? Okay. And if the answer is no, then where does everyone go? The brand has to be either saved or morphed into something, right? Yeah. Just replace it with something. Pick a word. People are being live and not agile, nimble, whatever you wanna put it doesn't matter. The core principles of what we used to call agility. They don't change, they still work. Small teams, rapid feedback, all of those things work, right? Avoid the tyranny of annual financing. Finance products instead of budgets only, or projects. Those things work, right? So in practice you apply them. You don't use agile jargon. And as we were saying at the beginning of the podcast, orient yourself to using business terminology with which business people understand. Hopefully, There was a agile manifesto, right in 2001. I'd like to see an agile postmortem, unadulterated way of getting whoever's available from the Agile Manifesto to actually honestly say what worked, what didn't stop hiding behind the veil of marketing. Step away from the fake stuff from your case studies and BS that have been propagated all over and have a true reflection of the world today after the impact of Agile. There are things that improved. There is entire disciplines like product management that emerged. Sure. There are things that got worse when the impact to the folks that actually embraced the discipline. I think I would love to see that because there are way too many arguments, even the same heroes, same 17 heroes. A lot of 'em conflict with each other. About who said what about the principles about things like that. I think it would be great to bring 'em all together and do the agile postmortem we need. If we are to preserve that brand and agility and actually recognize it, I think we gotta start consuming what we're producing and actually give back by explaining what worked well didn't. And if we had a way of changing it, how would we do it? That's interesting because well, first of all, I personally don't believe that's ever gonna happen. I know. I agree with you because these people have already moved away from. The original manifesto. So again, without naming names, I can tell you people have come up with their own little models here and there. These are the same people and they, it's not the same model. It's not like they're all gravitating towards the same thing or of the 17, not all of them are alive also right now. But , that's not it. They're not gonna do this because this has been a cash cow for them. Exactly. It continues to be a cash cow. So if it's not gonna happen, then what? Maybe something else needs to rise as a movement. Yeah. Whatever that might be. And I don't see the traditional agileists coming up with that.'cause people will have a trust issue there. Yeah. I think the trust issue, I think the scattered attention, people believe too many different things. It's a lot harder in the enterprise and startup space to be unique. Without receiving a lot of criticism. Some people will obviously adopt certain things like Marty Cagan's being recognized I think it's repackaging of the ideas for the most part. I don't think there's anything super new that can be created, but we've learned, right. What did we learn? Move small, get feedback. Right, right. But we don't do, we need a scrum master for that. Right, right. And, that's where kind of the reality and back to the beginning of the podcast where we are now. Yeah, I agree. I mean, I like you, you nailed the outro right there in the summary. I agree with everything you just said, Alex. The main reason that I wanted to push this up as a podcast was I just have this feeling that if the agile careers, quote, air quotes, agile careers are over, and like you just can't use the word Agile anymore. That forces you to re-look at the work that you were doing outside the scope of this. If I'm gonna call the Agile manifesto marketing thing in the first place, to convince companies you need to stop doing this big project management multi-month nonsensical process. And I'm gonna market my way around saying that's not cool anymore. The Agile Manifesto was a marketing scheme to convince companies that the way they were developing products was quote, not cool. If that was successful, what I'm saying is, okay, that ran its course. Now you need to take the value that you've been delivering to companies. And without hiding behind marketing buzzwords, you now need to refactor your resume. Uh. Show real business impact and remarket yourself as a different, whatever it is. I don't know what it is. I wish I could, I wish at the end of the podcast I could tell people you're a business consultant now. Just put consultant on the top of your resume and go out there kid and, get it. I'm not sure if that's the right term, but I am sure that those skills, those business leadership skills that you've been practicing as alist, whatever your role has been they're valuable. They are valuable. I'm convinced they're valuable. Yeah. I agree with that. I think as Agilist doesn't matter again with, you know without kind of regard to roles, scrum master, product owner, et cetera, you find a situation that you encounter and you do things and you hope to leave that situation. In an improved state. Mm-hmm. Right. So what is that, that's changing? I mean, you're really a change catalyst, although that's not really a title that anybody likes, but focus around what has it meant to the businesses that you've worked with as opposed to at the team level? Forget about fake metrics or vanity metrics as we call 'em. Forget about all of those. I mean, they were done a long time before, but now they're truly buried. Right? Sure. Nobody cares about your, CFDs. I mean, they're good as far as tools to improve, but they're not something you lead with when you go in and interview. Right. Velocity and all the likes. Well, the agile community's missing is redefining the agile track. You know, back when we were starting the careers and I went into computer science, my sister went into information systems. We all had a different career track. Her career track was qa, project management. That was the career track and information systems. Yeah. My career trek as a computer scientist was engineering development architecture engineering manager. Somewhere along the lines, the track allows you to jump different areas. Project manager allows you to jump to program management or engineering management. The software developer has a lot more variety. They can continue along the engineering route, principal, architects, et cetera, so forth. They can stay on the development side, they can jump into executive side. There's a lot more versatility, security, et cetera. I think the agility is the one that doesn't really have a track. It was always a one path boom. Agile. Agile, right? Yeah. And that needs to be redefined. What is that track now that we've reached that last step on the rung, that's no longer available? Where's the next one going? Yeah. And I think as we, as we talked about it, is back into the business consultant, it is back into the directorships. Continue improvement. But don't go, don't look down. Look up. You can do a lot more if you step away and just think about the impact you've driven. Right? You can lead organizations, you can help run products, you can help with quality, you can help a lot of things. You just have to stop sprinkling the agile jargon all over the place because nobody cares anymore. So I don't know if we have declared Agile completely dead as a brand in this podcast, but I think what I said in the podcast holds true, which is the skills and experience, especially the experience that you, that anyone listening to this has the taking teams from like teams off camera to teams on camera, type of like developing the team. Like those are real skills that you have done. That because you can't get a job now for six months, eight months, whatever, because like these agile jobs you're looking out for have disappeared. That's not a reflection that you are not valuable. Right. Like I want to tell people and let people know Hey man, it's like stop despairing. You have solid business leadership skills that you have learned. You've learned through doing it, and you've learned through experience most importantly. And yes, maybe the people that you're interfacing with don't value them. Go find other businesses. Maybe they only value them like 10 hours a week, 20 hours a week consultancy or something like that. There are businesses out there that need your help. Get out there and find the people that need your skill. Is, is, is my main thing that I'm trying to get across in this podcast. Again, that's the main seed that, that, that I wanted to have this podcast thanks to Alex for coming out and weighing in.'cause I I, I, I didn't just wanna be ranting at the camera for an hour on this podcast of Hey man, you, you is kind and you is special. I wanted to be listen, like you, you have skills. No, it's great. It's great being there. I being here with you guys the, the topic is important. I think Agile will have a long tail. It's, it's too finely ingrained everywhere. It's very important. It's not gonna disappear. However, the roles, the traditional roles that fill it will be less and less available. Sure. So we'll start transitioning to something else. Mm-hmm. AI will not replace that thought. However, there's gonna be some conversion to different roles. But I agree with you. Every agile professional has a lot more value than what they're able to describe, at least in the terms that everyone has been. Right. It's not about backlogs, it's not about Jira, it's not about tickets, it's not about all these things. Sorry, did you say it's not about Jira? Oh, yes I did. Oh, I'm sorry. There's a, there's a special sound effect that is a special sound effect. All right. So those of you that are still with us, both of you don't forget to like and subscribe and let us know down in the comments below what other topics you'd like us to tackle. And thank you for coming.