That Change Show

Agile Transformations: What's the Problem?

January 21, 2024 Lean Change Management Season 2 Episode 2
That Change Show
Agile Transformations: What's the Problem?
Show Notes Transcript Chapter Markers

On Lean Change TV: https://leanchange.tv/videos/agile-transformations-whats-the-problem-that-change-show-s2-e2

Ever wondered why, despite its popularity, Agile transformation can feel like swimming upstream in the corporate world? Join us as enterprise coach, Ken Rickard, and I dissect the reality behind Agile's application in massive organizations. Through candid conversation, we unravel the paradox of Agile's allure versus its on-the-ground challenges, especially under the financial pressures that tend to sideline coaching teams when the economy takes a dive.

This episode is a treasure trove for anyone struggling to maintain Agile methodologies amid the whirlwind of changing company priorities. We scrutinize the delicate act of balancing adaptability with the comfort of well-worn paths, considering the financial intricacies that make or break the success of Agile coaching ventures. The dialogue doesn't stop at methodologies; we dive deep into the broader implications of Agile adoption, scrutinizing the true worth of certifications and training in the corporate realm.

As we wrap up, Ken and I address the pivotal mindset shift leaders must embrace to drive genuine transformation. We shed light on the confusion stemming from overlapping process improvement strategies and advocate for changes in core beliefs and behaviors over mere process optimization. With a glimpse into the future, we share our enthusiasm for the upcoming session in New Orleans and Agile 2024, looking forward to helping organizations evolve through our insights and experiences.

Jason Little is an internationally acclaimed speaker and author of Lean Change Management, Change Agility and Agile Transformation: 4 Steps to Organizational Transformation. That Change Show is a live show where the topics are inspired by Lean Change workshops and lean coffee sessions from around the world. Video versions on Youtube

Speaker 2:

All right, we just agreed that we were going to get all our coughs out of the way before we started, but I guess I lied. Welcome, sunday, january 21st. That change. Show Again. Live off the cuff 30, 40 minutes or so. And the topic of this episode is our Agile Transformation Still Relevant. So that topic was picked because I don't know. The LinkedIn algorithm seems to know when I want to do a topic on something, because it starts just presenting with horribly incorrect information about Agile in general to me and it just makes me angry. And normally this is a solo show, but I'm excited that Ken Rickard is joining me all the way from Florida.

Speaker 1:

Sorry, it's about as cold as Canada here, so yeah, Right on.

Speaker 2:

So for those who are listening on the podcast, we might have a couple of little images we're going to show here and there so you can always catch the video versions of this on leanchangetv, and that'll get you through our YouTube channel and you can check those things out. So, ken, why don't you give us a little bit of introduction about yourself?

Speaker 1:

Sure, yeah, I tend to think of myself as an enterprise coach, agnostic of any one particular way of doing things, but kind of more of an alchemist. From a change perspective, I currently work for a company called Insight, although I do a lot of nights and weekends with Jason as we build up things for leanchange and new ideas for a transformational space.

Speaker 2:

Cool, and you have recently just become a.

Speaker 1:

I-C-E-E-C Holder, which is an expert. I was like to put air quotes around that. Whatever that means, enterprise coach.

Speaker 2:

Right on. So the interesting thing about that is I wonder if this whole world of Agile transformation would be in a better spot if that existed beforehand. Now I'm, again, not huge on certifications, but I do know how that was created and who created it. Yeah, obviously it's coming from Lisa Adkins amazing work and Michael Spade, and who both come from organizational change backgrounds, which is fantastic. I don't know if I'll get in trouble for saying this or not, but I remember we brought them up to do a course for a client up here a big client, I would say and we actually funded it, because the funding process to actually get it approved and get them up here to pay for it would have taken six to eight months. So us, the outside consultants, actually funded it, and I remember a buddy I was working with he said let me get this straight. So you're telling me that the four of us are funding a multi-billion dollar company to pay for their training and we build them back for it every month. So we just added a little bit months to pay back. So I'll probably get in trouble for that, but at least I didn't mention the client, but anyway. So this you know. When I think about Agile transformation. I guess I started working on them in the mid to late 2000s and I was late to the party. I mean, capital One started in the early 2000s. I think every coach I know in the universe worked at Capital One at some point, probably as early as 2002, maybe. But that's been 20 years of ups and downs and waves of this and that and processes and consultants and stuff. And last year I know they laid off about a thousand of their quote unquote scrum master slash delivery managers and that's been a bit of a trend too. Agile coaching teams, complete Agile coaching teams, getting tossed. I've seen that in some of the banks and insurance and stuff and I'm wondering what's going on with Agile transformations. Are they still needed? Are people still doing them?

Speaker 1:

Yeah, Well, I don't know. I mean to me, I think you know most organizations, especially the financial institutions and the telecoms and health insurance, which are the bulk majority of the folks that are trying their best to take on a quote unquote transformation. You know, most of these organizations are so big and so lumbering that when they say they're going to take out an Agile transformation or they start Agile in pockets and it starts to grow a little bit, it's really kind of dampened by the whole size of the organization and its unwillingness to change. So they're probably doing things in small pockets and doing fairly well, but also hitting their heads up against the ceiling of improvement because of the size of the organization and the complexities of it. So when time comes in order to tighten the bell, it often seems that these are the first things to go, because it's the initiatives that are helping them change into something new that they would rather just kind of put on the shelf or put on hold in some way, while they just kind of hunker down and kind of wade their way through these tough times. And those ebbs and flows come and go is what I've seen. And so we'll go through periods of coaching being a very popular thing, agile and Scrum, things like safe, being very popular, and then we kind of have to tighten the bell and then we see all those things kind of go away for a year or two, or at least not be nearly as important, and then, as soon as things start to get better, then okay, now we can all rush back in.

Speaker 2:

Yeah, that's very similar to the company that I mentioned, where we paid for the training Cost center versus value producing center and if you are perceived as a cost center and not providing direct value. But I think that's the way business has always worked. I don't think it's really specific to Agile, transformation or coaching groups. I think that's just always the way it's been. It's somebody at the top is looking at a spreadsheet and goes, oh shit, we need to cut 30%. Who doesn't make stuff Right?

Speaker 1:

exactly yeah those are supporting roles, Because when you're kind of in that hunker download, I mean the support roles are really what's not needed, because the support is what's there to help you change. And so if we're not going to change because we're going to stand still, we're seeking stability as opposed to adaptability. Then the idea of us needing the people who help us change is obviously not as important at the time as it will be in the future when we decide to start changing again.

Speaker 2:

Yeah, in our case there was obviously everybody's got a budget for their Agile transformation because somebody's got to pay for it. The way that we had structured it was, I guess, like a tax almost, so X number of dollars was dedicated per team and the teams that really wanted to change would use that budget for coaching. So it was basically you have X dollars which buys XY days of a coach for your team. That's all you get. And teams could also just take that budget and say, well, we don't want a coach, we're going to use that extra X dollars for more features for the project. So we kind of had to shoehorn it into like this even went to the statement of work. We had to phrase it as project augmentation in order just to work around the way funding works and stuff like that. Right, yeah, so when I see these, I guess the two camps right, there's the left side manifesto camp, which is the honor. It's about the manifesto. You're not doing Agile right, like the extreme side of the left versus the right somewhere in the middle is those organizational realities are always going to be needed, whether that's Agile or not. It is kind of irrelevant yeah.

Speaker 1:

Yeah, you know, agile being a Word that stops around a lot, I feel like they they'll be more. There may be some more Likelihood that agile would get kind of set aside then, just plain old, everyday kind of changing initiatives that are trying to help the organization approve. I don't know, but Agile, as of late, has certainly become a trigger word for a lot of folks and many organizations who have decided they don't need those Kind of attributes in their organization. Right now the number of coaches seem to be looking for jobs on linked ends is Astronomically higher than it was just two years ago, you know. So I think that's it's a. It's a really interesting time. It reminds me of the kind of ways to change. You know that you laid out and, and then of course we come back there and put it more to a transformative kind of approach where the five waves equals some kind of motion through, you know, a change at the, at the personal level, because people, you know organizations are made of people, and who was it that said that every problem is a people problem? Jerry, one bird, or was it Virginia? Sit here.

Speaker 2:

I can't we always?

Speaker 1:

One of those originally said it but the organizations themselves. If, if we're not changing at a people level, then most likely we're just kind of going through the motions in some way. You know, we're swapping one Part for another instead of actually addressing the entire system. And so those, those five waves of change, and we'll put the image up. He said in the background or something right, so for the folks that are not watching the video may have to go there and look. But the you know the the waves move from this kind of superficial only swapping out technology and process because that's what we can control and what we can easily change and to actually starting to address the system by the third wave and then eventually into the collective of the people, recognizing that, hey, we're all collectively responsible for what we're doing now and if we're going to change it, we all need to change in some way Then to eventually into the fifth wave being about yourself. So you can only control yourself, can't control everybody else. So if you start with yourself and you start changing yourself and it'll start your movement I'll be it slow and yet guy patients, but it'll start a movement within an organization, from within.

Speaker 2:

Yeah, that that idea was, I guess, kind of born Through observation. So you know, back in the early 20 tens I guess, when agile transformation was a huge deal, like here around the Toronto area all the banks, telecoms, everybody. Even earlier, I think one of the telecoms I think it was 2009, eight when I started working with them and you know, over the the next 10 to 15 years, the pattern became pretty obvious. It was kind of close to an 18 month cycle for enterprises where, uh, you know, the year long transformation program has run its course, the VP of agile or whatever it is is tossed in favour of a new one, or the consulting firm is tossed out and a new one is brought in. And because we always use the joke about this that you never want to be the first people in there, because it doesn't matter what you do, it ain't going to work when you're in the first wave, the people, especially in enterprises, they've got to live with agile through all of their Existing ceremonies for at least a year, 18 months, two years, before they really understand how it's going to affect things. Like I went into this insurance company and they were. They just finished. Their annual planning was, I don't know, august, september, ish. So all their budget was done, all their programs were done. One of their programs was an agile transformation and I actually talked them out of doing anything with it because that is just, it ain't going to work. You've already decided how you're going to spend all of your money. Your whole next year Is basically going to be whoever's in charge of this program Running headfirst into a wall for a year Because nobody can change. You've already decided what all the other teams and things are going to do. You might be able to sprinkle some agile dust and some process on them to make things a little bit easier, but you know, I don't think it's going to work. What you're going to get out of that is you're going to see how much of a Disruption agile is going to be to your organization and then the year after that, now, when it comes back to doing your annual planning which, by the way, don't do that anymore when it comes time to do that now, you're going to have some good insights and ideas about how it's going to affect your whole company. Now you can actually Probably do something about it, and then the second wave is going to start and then it's going to get a little bit better. And I mean we, we would get into an organization, we would know what coaching or consulting firm was there before us. Yeah, it was like, you know, be the second or third wave because you can come in and do the same thing. Yeah, the same language, but now people are ready because they've lived through it.

Speaker 1:

Yeah, it's almost like the big consulting firms come in and they help an organization or a group being a team or a program or you know some kind of product being built, but the idea is that they'll often just drop off playbooks. So that's definitely first wave behavior. You know where, like, oh, there's this cookie cutter thing. We just need to do this. You know, back in the day it used to be Spotify. Everybody just wants to try to emulate Spotify. I mean, there's still some organizations trying to do that now, but not nearly as many. But whatever that cookie cutter approaches like just bring it in and whatever it worked over the last few years, but whatever that cookie cutter approaches like just bring it in and whatever it worked over there for them, obviously it's gonna work for us. We want to be like those guys, you know. So, yeah, I wish you know. You you kind of put this premise out there in the beginning of you know, our transformation is so relevant. I was just talking to another ice holder. Um, actually, I found a lives here really close to me the other day and we were sitting down from launching and and chatting over things and, um, I had said to him I said, you know, I wish, I wish organizations would stop focusing on things like scrum and and agile, on transformation and all that, and I wish they would just focus on two things. They really only need to focus on two things, and it would be that they are adapting in the short term to the change that they can't control within their organization Because it's coming from without or outside of their organization and they don't control a society, they don't control industries and markets and they don't control their competitors, but then in some way they have to kind of react to those things. Hopefully, they're leaning into that and it's a little more proactive than completely reactive, but that they're adapting and changing in the short term to what's going on around them and what they need to do, but that they're also evolving over the long term through that adaptation In order to keep evolving and keep getting better at responding to change. And if organizations can just focus on those two things and and not directly focus on all the other things, um, because what falls out of that will happen organically, as long as they enable the system To work together towards continuous improvement. Um, but yeah, you know, we love our off the shelf, uh, you know, hey, uh, agile forward 499.99. Yes, please, I'll take that right off the shelf and and just install it in over here. Um, just hit the play button and it'll run through and install and then we'll be fine after that.

Speaker 2:

So, yeah, wish it wasn't so yeah and uh, when you get into enterprises too, because they've gone through it so many times, like you said, it's just Uh, exhaustion. I think that's why we see the new ways of working, as the Aussies have called it, because they were all fed up with agile. Um, yeah, right, yeah, but it's the. The thing is, you know, I'd argue, we're in the, we're in the late majority phase of agile, if you will. You know, 2012 ish is when agile started becoming a big business. That's when a lot of the scaling framework started gaining in popularity. Um, you can. There's a company called version one, which I know you know about them, but for the listeners out there, version ones been doing state of agile surveys since 2006 or seven, somewhere around there, maybe 2008. It's been a while. So they've been tracking popular methods and stuff like that, and you can just go through those reports or, even better, dump it into co-pilot or gpt and have it analyze them for you. Um, side note, we actually we did a decade of agile report manually, um, after their their tenth one to analyze those patterns, and as soon as it became a way to print money, the intention of agile kind of got lost, like the last dumb thing that inspired this show was. I saw somebody post on LinkedIn the most unagile thing you can do is release every sprint and I was like, what the Like? What yes, Separate would you from should you be able to? A lot of people don't understand, because I've seen this a gazillion times in Agile, as most Agile coaches have never written software or worked on a product team and the change managers who are getting thrown into Agile transformations certainly have no idea about how to build software and that stuff. So when you're, if you haven't done it, it's harder. But you talk about yes, you should be able, it's potentially shippable, increment, that's the phrase. That means yes, you should have something potentially shippable at the end of the sprint, but that's as far as it goes. So now people read that and they go oh, you can't release every two weeks, we're on a three-year program. Well, agile doesn't say stop thinking, but if you don't at least get the basics right, the LinkedIn answers thing. I think that's making everybody really stupid with respect to Agile. I saw one the other day. It was how do you use the daily standup to solve team problems Like you don't solve problems in the standup? The purpose of the standup is to plan the day to get you closer towards the sprint goal.

Speaker 1:

Yeah, I know you just get ready to put your AI for change managers book out. One thing that I'm waiting to see is that, with the large language models, whatever's put into them is about as smart as it'll be coming out, unless they can build it to be more learning than that and it can actually learn things based on data it didn't ingest. I'm not sure if that's a thing yet or not. Maybe the future will be, but I keep thinking about the internet, linkedin, social media. The things that are said there are point of view opinionated, often, at times at least incorrect in their interpretation of maybe what one thing is or isn't, and, of course, then nobody agrees anyway. So how are we going to build a single model that? Is it going to need to have 50 answers and so everybody gets their own answers? So then we all are still in the same place, but if it only has one answer, then now we're all dogmatically learnings jumping off the cliff. So I don't really understand yet what it's going to be. It's going to be really interesting, though, because I think there's some danger there and that if what's fed into it is all the same and also, by the way, it's the commodified dogma of agile and things like scrum and safe, then anybody who uses those models is going to get those type of answers. It will only reinforce the bad behavior that's currently exist on social platform. Now that's my concern.

Speaker 2:

Yeah, yeah for sure, especially with the rush to create coaching bots and stuff. They're informational, but it's exactly what you said. It depends on how people are training it, because I can make a closed ecosystem bot which is my data. I can train it to answer things the way I would answer the questions, and that is very scary because you could use any AI system to ask a question. Then you can ask a specific bot that's on the GBT store and get a different answer, because you'll get somebody who's trained it. If you got started in Enterprise Agile after 2013-14, there's a pretty good chance you're more biased towards process and that's obviously not the case entirely. But it's like there's a great book called the Kingmakers and it describes this idea about baby duck syndrome, which is the baby duck syndrome. I hope I get this right. I'll put it on the screen if I get it incorrect. But when baby ducks are born, if the first thing they see is a dog, dog is mom, it's imprinting, it imprints it into the brain. That's the first thing they see. Yeah, so the new Kingmakers talks about this in a developer context, which is developers fall in love with the first language that they use and nothing else will ever compare. This is why you get these 20-year experience developers who really have one year of experience, the same one year 20 times over. They just rate Java, they just rate NET and they might be fantastic developers in that one language, but the landscape is totally different. I think it's the same in Agile. You fall in love with the first Agile transformation or process model that worked well for you and then now that's the truth. So if safe worked great, safe is now Agile and I could care less. I don't care about frameworks. I think most Agile people are mad at safe because they're not the ones printing the money from it and they didn't create it first. The intention. If you go back to it Dean actually says this and throws some angry comments. If I got this wrong, but I'm pretty sure I read this you don't use safe to scale an organization. You use it when you're already a gigantic company and you want to organize your people differently around the work. But you see, that diagram and it's just like that's not Agile. Or you look at the pastel version of it, like Juergens, which is basically safe with pastel colors, and people see those things and they see prescription Since you're not as active as I was.

Speaker 1:

I had a random everyday friend that I couldn't recognize. Yeah, I think through the years we've worked together, I think I've become increasingly less attached to the types of agile frameworks that are out there In a good way. I think I just not paying attention to it for the most part altogether, because I think I used to be so dogmatic around things like Scrum that I think I wasn't helping. So I just decided to stop stop kind of dabbling in delivery all together and just start coaching towards leadership and organizational change. I have more passion there to begin with, and then it gets me out of the weeds. So I think getting out of the weeds was good for me, because then I don't get so hung up on the well, it has to be this way. All right, this is the framework, this is what it says, like we need to do that this way, which was a lot of how it used to be kind of grown up. I mean, I've been in the agile industry for 15 plus years I think at this point, and it wasn't until about the past five years that I really started to shift that behavior. So yeah, I think it was through just trying to look outside the bubble of things like Scrum and decided Scrum's great, it works and it has a need and it can fulfill a need, I should say, but it shouldn't be applied dramatically and it shouldn't be the only thing. So much more kind of agnostic in that way, and I think the industry at large is too focused on frameworks too. I think we're starting to see that out of a lot of folks that they're really starting to be this pushback against Scrum and SAFE and for various reasons, but in part I think it's because there has been an overindexing or over-emphasis on frameworks and so we've got to commoditize in that realm and I think it's time to get back to basics. I hear a lot of people talking about that, trying to get back to basics.

Speaker 2:

Yeah, simplify because I think the more you use and try things out, the more you realize they don't have to be that complicated. We don't fight complexity by making things and processes more complicated. We loosen the controls and the constraints and we let the brain, which is more complex, deal with it and the interactions of the people in the systems, which I think is good. A company I just did some work with a couple of weeks ago and this has been because you talked a lot about stance, like how your stance shifted the five years ago, and my stance has always been, when I am hired to do quote unquote training, I'm always talking about by the book versus the real world, always. So we talked a lot about how do we deal with this particular problem which is getting interrupted in the sprint too much and then we never finish the sprint commitment and stuff. And the teams weren't stable completely and we just talked about well, here's how it would work in scrum if you were doing it by the book. And I even told them. I said I don't know. I've probably worked with thousands of teams and I've never seen one that has ever done any process modeled by the book. It just it can't happen that way because the process models don't understand your context and the conversation was great. It just kind of switched their view and their stance to oh, maybe we shouldn't be looking to be more agile or follow scrum better? Maybe we should try to figure out how we use the 12 principles to figure out what's important for us and use that to help us decide what to do as a team.

Speaker 1:

Yeah, I mean, certainly being more adaptable is gonna be a good thing. The challenge I think a lot of people in organizations have those that they're coming from a very rigid top down and this is gonna be like, yeah, obviously, but I'm probably saying in a slightly different way than hopefully people are thinking. But they've come from a very rigid kind of top down approach where things like the pin back right, the project management book of knowledge was the thing that got into every move and it's laid out in great detail and we just have been conditioned in those systems to look for the instructional orders that are to the nth degree of what we're supposed to do. And if it's not going to look up in a book and it's gonna tell you what to do, well then it's your leadership or your kind of management above you that's kind of disseminating those instructions down to you. And so I feel like we've been conditioned to look for that. In walks, things like scrum with a minimal guide, you know, in walks agile, which is for values and 12 principles, and so our natural tendency, given what we've been conditioned to do, is to go oh wow, this is really lightweight, but it doesn't suit my needs. So let me plug the things I know into the holes that I see, because it isn't fully defined in their minds. So they kind of like okay, I see the reality of scrum, and then here's my reality. Let me merge these two things together and so that's how we get this kind of like hybrid approach and companies that are transforming me yet not really changing anything. Pretty unfortunate.

Speaker 2:

Yeah, I think the, the, the, a lot of the companies today, because they've been at it for so long. This is why I was thinking our agile transformation still relevant because they've been going on for so long. They're already in their third or fourth wave of Infinite number of waves. It's not like there's a finite amount. Once you hit wave 5, like CMMI level 5, you're done and you're good it's. The waves keep going because all companies keep evolving, all the, the coaches At least from what the enterprises here are hiring for our established roles In a department that is more acting like a process improvement department. So, you know, back in the early, early 2010s there Maybe there were a couple of companies doing agile coes, but it was very misunderstood what an agile coach was supposed to do. Nobody knew. It was just like, oh, I guess we need an agile coach. And then, as companies started learning, then they started adding stacks of hierarchy. So they, they, they might already have a lean six sigma or process of improvement group. Then they add an agile improvement group, which is a different stack of hierarchy. Then when lean startup and intrapreneurship which I don't think I've heard anybody talk about intrapreneurship anymore the way it used to be after a lean startup. Then they spun up a stack of that. Then they spun up a stack of design thinking people. Now you've got A project that you're kicking off, that they want to transform, and you've got five people that are basically they're in their purposes to do the same thing, which is to help the team work better, and they've all got their individual objectives and they've all got their individual process models and it's it's just compounded the problem. But now those are established groups in organizations, so when they're hiring for coaches, they're just plugging you into an ecosystem that's more about process improvement and they're not necessarily starting a transformation.

Speaker 1:

Yeah, yeah, it gets some. You know, one of the things we've been talking about and working on is the, the two change strategies to effective organizations, and what you're nailing right. There is the optimization one of the horizontal growth, because a lot of organizations Really don't want to change themselves or evolve themselves or transform themselves. It tends to be that they want to stay mostly the same, but they just want to get better at what they're doing now, and to me that's optimization. And so, even though the word transform or transformation is thrown around in a lot of organizations, really what they're doing is optimization on transformation. This transformation requires you to do something or to succeed in ways that you never have before, and To get that it means you have to vertically change yourself. So you, you raise a plane of existence and being so, your beliefs change, your, you know, your behavioral patterns change, and vertical development requires you to Take on a whole another set of beliefs and actions, and without that you're not transforming, you're not evolving, you're just staying in the same plane of existence and you're just kind of leaning out or optimizing what you do now to get narrower and narrower.

Speaker 2:

Which is ultimately?

Speaker 1:

turning you into more rigid and rigid. So you can't just optimize, you also have to evolve.

Speaker 2:

And you can't just evolve, you also have to have a nice. Do you think leaders are more open to those kind of conversations now than they used to be? Because a lot of the knock on Agile was kind of the woo-woo nature of it. It's about beliefs and mindset and being agile, not doing agile, all that stuff. And there's no way you could go into a C level office and talk that way. It'll throw you out. But do you think the landscape has changed? Where leaders are less, I think leaders get a bad route. To be honest with you, I, I but well to.

Speaker 1:

To Back in the day this was probably, I don't know, 20, 2014, 2013, somewhere around there Um, you know, I walked into a cio's office and was talking to about agile and Um. We got into a point where we were talking about the difference between of course this was when this phrase was big Uh between doing and being agile, and he literally laughed me right out of the office. I so that's interesting, you brought that up um more recently, just last year, there was a kind of more senior director with an IT I was kind of workshop with and we were talking about, you know, the behavioral patterns and those kind of things that would need to shift in order to vertically develop, not just optimization, and he kind of jokingly in some way said why didn't realize I had to become a Buddhist in order to practice agile, you know? So there there's a bit of that that still exists, you know. But I think you know the rate of change Change that can't be controlled by any individual, necessarily Um, highly complex change. Um is More people are more aware of it now, especially in leadership positions. Uh, the digital age has been around long enough that it's kind of created this age of complexity, and so I think that has been recognized enough, um, that more and more leaders are open to the idea that they can't possibly Figure these things out unless they start to change their system. Now, I still believe that most of them think about optimization, no matter what they call it, they're still trying to optimize their systems or the parts in their system. They're trying to look for problems, isolate and analyze those problems and then ultimately try to superficially or symptomatically solve for those problems, as opposed to doing it the more of the diagnostics, where the synthesis of the system as a whole, and then try to send your way through the system, um, in order to then respond to the system and see how it responds. Um, so I don't think they're they've not learned those those things yet. Um, I don't. I'm doing a good bit of trying to get those concepts in front of leaders, um, and it's the general rule of thumb. I've gotten very good responses in the past year and a half or so from Uh people in leadership positions that are recognizing that they can't operate in the ways that they've been operating and still succeeding.

Speaker 2:

Yeah, you've been talking about the five levers of change for quite a while, the levers that you're describing. There are things we can see. Anybody can muck around with an org chart because it's visible. So it's the visible versus the invisible. We seem to focus our attention on the visible because we can see it, we can touch it, we can move it around, we can see cause and effect. And I put up some bunny ears air quotes because you can't really. But you'll see, hey, if I mucked around with my structure and I reorganized my teams this way, the output was worse. Therefore, like that kind of reductionist and simplistic thing, it doesn't work. But yeah, maybe they are more open to looking at the other levers, because you've got to make an impact. If you come in as either a consulting group or the new transformation leader or the new VP of Agile or whatever, you've got a small window where you have to prove your worth. So you have to pull visible levers. But maybe that is going to be the next shift with Agile transformations, as we start to look at those other levers.

Speaker 1:

Yeah, I think the pandemic really helped you because I think that level of chaos that everyone was experiencing at the same time I think really leveled the playing field in a lot of leaders minds as to, okay, we're all in this shift together, whether it feels like it at times or not.

Speaker 2:

I mean.

Speaker 1:

I may be in this position and this part of an organization and this company and I have competitors, but at the same time, when things get really crazy across the board, we're all in the same boat and we all have to deal with it in very similar ways. So I think that kind of unification moment probably helped a lot of leaders recognize that these kind of chaotic situations can creep up at any time now and smaller events are happening pretty consistently on a regular basis and aren't global pandemics, but that level of chaos being injected so quickly.

Speaker 2:

I think, caused a lot of leaders to realize that they can't just do this the way they've been doing it. You've got to shift something, yeah. So, as we get into the wrap up, what would you do if you get tossed into a transformation situation? Now, in today's context, it's going to be. Obviously they've been dabbling or trying some things for a number of years potentially and they want to restart. Like maybe they hit the bottom of the wave and now it's like okay, we think we get it. We know Ken's the best in the world. Here's $40 million. Transform us.

Speaker 1:

What are you going to do? Yeah, I think we're old Ken from years. Yesterday would have probably just dove right in and started teaching people frameworks in hopes that they would have some epiphany, and like oh well, we've just been doing this wrong, and I think I've done enough of that in the past and I realized that that isn't what's going to work. I've become much more patient, much more wise about these things, and so I think the first thing I would do is I wouldn't gravitate towards that kind of delivery agility frameworks, stuff. One of the other concepts I've worked on is the three agilities. I would actually lean to the other side of the three agilities and I would go to the change agility bucket of things, which is really helping people to understand what and how they need to adapt and then what it is they need to do to evolve over time, and more of that vertical sense of development, so developing self, and that's really hard, it takes a long time. So you could have a track of vertical development going on. At the same time, you could have optimization going on, because, hey, they're already doing something, they just need to. They're probably thinking about, well, would you see, to do this better? Okay, great, let's entertain that. But at the same time, you're never going to actually get above the ceiling that you're currently at unless you start to focus on vertical growth, vertical development of people. So I think probably the first thing I would do would be to start putting those vertical kind of deliberately evolutionary ideas in front of these people at the organization so that they could start to see that they have to start looking beyond optimization towards evolution.

Speaker 2:

Yeah, that's a good point. That just clicked in my brain. It's not an either or. It's not vertical or horizontal, it's both, and it's the timing of when you intervene, I think, in each of those axes.

Speaker 1:

Yeah, the gap in the short term, evolve in the long term right and respond to change. You know change that you can't control. The evolution is to help you respond better to change in the future. So we've got to evolve, which is that vertical growth. But at the same time we can't just focus on evolving because in the meantime we still have to get stuff done and we still have stuff to apply and we're still we work the way we work now, and so that's really about the optimization. So adapt or optimize in the short term while you're also focusing on evolving through iterations, which is the longer. Longer path, obviously adaptation, optimization type stuff. The shorter path, evolutionary things and evolving the organization or the system longer path.

Speaker 2:

Yeah, yeah, the. I remember I'm pretty sure it was Johanna Rothman who's written, probably, in my opinion, the best agile books out there. This would have been a long time ago at AYE. I remember her saying something like if you really want your company to be agile, just cut 40% of your projects and watch what happens. And I worked in a place where the VP of transformation did that. He just said they had data that said it was 14 to 16 months median delivery for projects. He said deliver something every six months. That's it Like you talk about a chaos grenade, right. So that forced, I think, a trigger in both axes. But yeah, so tell folks how they can get in touch with you or find out more about stuff that you're working on.

Speaker 1:

Probably Lake Den is the best place. I tend to pay attention there, the most post there occasionally. I think I'll probably start posting there more this year. We've got a number of things in the works, so I want to make sure we get those things out there. I usually post there more often. I usually post about my classes there. So I do teach the ICI Giles Enterprise Coaching Track courses, so the ICP, ENT and the CAT, and then, of course, I teach your Lean Change Asian Foundations course as well and all the Lean Change stuff. I usually post about all those things on LinkedIn.

Speaker 2:

Cool, yep, and I know are you going to be at Scrum Gathering, so did you accept the thing? Yeah, yeah.

Speaker 1:

So May, I think it's like the third week of May or something I think my session right now is on the 22nd of May, down in New Orleans. Yeah, we'll be down there talking about how to get your transformation air quotes unstuck with these adaptable techniques within organizations.

Speaker 2:

Yeah, cool. And then hopefully Agile 2024 will both be there, so we can overdose on the Rubik's Q.

Speaker 1:

Yeah, We'll likely sponsor again for Booth and then, yeah, hopefully we get selected to do a workshop and do our individual sessions. So, yeah, we'll be there.

Speaker 2:

Right on All right. Thanks for taking the time on this nice sunny and warm. It's only like minus eight today, or something in Canadian degrees, so thanks for taking the time. All right, all right, yeah, thanks.

Speaker 1:

Jason Appreciate it.

Speaker 2:

Okay, all right, thanks for your time, I just вел off to construction. No, nothing did it.

The Relevance of Agile Transformation
Agile Transformation and Coaching Challenges
The Challenge of Agile Transformation
Adapting and Evolving in Agile
Leaders' Mindset Shift Towards Transformation
Change and Agile Transformations Explained
May Session and Agile 2024 Plans