Why Agile Fails - Lee Wiesehuegel

Coach Lee tells us "why agile fails" at scale and what needs to be addressed to reduce the chances of it happening to you and your organization. Most of us know that Agile is easy and effective on a single team, but those of us in the business of Agile Transformation are not working with single teams - we're working with large corporations, multiple departments, external service providers and dozens upon dozens of teams.

So how do you avoid failure with agile at scale?
3 key elements of agile at scale

1. Teams
2. Backlogs
3. Working Tested "Stuff" (software, product, etc.)

3 areas that need to change

1. Structure (of the teams and their relationships to one another)
2. Governance (who makes decisions, how they are made, when they are made)
3. Metrics (what we measure and how we respond to what those measures are telling us)

Questions? Email me or Lee at
Kyle.Spitzley@Amway.com
Lee.Wiesehuegel@LeadingAgile.com

Transcript

Unknown Speaker : 0:00

For agility say,

Unknown Speaker : 0:05

Hey everybody, this is Kyle Spitzley. And in today's episode, I get to talk with Lee yc. Google Cloud, why agile fails. And he tells us his stories, his examples, lots of details about what he's seen or why this happens so often, and how we can avoid it happening to us. So we have a great amount of detail and an awesome conversation. But just to give you a taste of what's coming. Here's a 62nd summary from Lee why agile fails, enjoy the show, have a great day.

Unknown Speaker : 0:37

Organizations fail, it's because they don't establish those three foundational things teams backlogs, working tested software, they don't approach it from a structural practices and a cultural point of view. They're not looking at the holistic picture at scale right struck the structure of teams together. Even with the dependencies that they have, so how workflows how we must orchestrate things that we can't encapsulate, and how we measure know whether or not we're successful the metrics. Then under also understanding to what level of agility we must achieve for our organization to be successful, and taking that intentional journey through there, right? So organizations fail because we fail to recognize those things, or we fail to put in the hard work that's actually required. Right and in light of what's there.

Unknown Speaker : 1:34

Hello, everyone, and welcome to the show. I'm your host, Kyle Spitzley. With me today is Lee wisely. Whoa, girl, how you doing Lee? I'm doing great. How are you? Very good. Thanks for joining me today. So Lee, if you don't mind telling our audience a little bit about yourself?

Unknown Speaker : 1:51

Sure, sure. Sure. I'm a long time, software kind of guy. I've been working in it. Since I decided to grow up and have a family and you know, had to get a real job, right, it was like a passion to work with computers and programming and things. And so I've had all the kinds of jobs I've been developer, I've been infrastructure guy, business analyst, traditional project management, Program Manager, agile project manager, and agile coach. And I recently, you know, within the last year, joined company leading agile in August last year. So coming up on here, because I wanted to get out and see the world so to speak, and get to work with more really great and amazing clients on their agile transformations. I had experience at at a really large enterprise, applying agile transformation in a group, one business unit, which was about 12,000 people in that unit in the IT side, so it's large, large scale stuff. But that's one point of view. And I'd work there for a long time. So I wanted to see other things. So. So here I am getting to help Amway with their transformation. And I've met a lot of fantastic people with some really great attitudes that are excited to get to work. So it's been fun.

Unknown Speaker : 3:19

Yeah, it's awesome. One such a breadth of experience. In your past, I didn't know that you had that many different roles in the technology space. That's really awesome. It's been awesome to have you on the team working with us. I always appreciate your insight and some of your your wisdom from your past. And so what I wanted to talk to you about today, and I think this is a question that I hear a lot of why isn't it? Why isn't it working the way we wanted it to? Why is it so hard when we talk about implementing agile or transforming teams to become more agile, as well as transforming an enterprise at scale, with agile so the question is, why does agile fail because I've seen So many, you know, case studies and summaries of how well it's working for organizations, and there's there's organizations and companies out there that are just killing it in the marketplace with their agility. And we look and we say, we've been trying to do this for years and trying to make this stick and really take a look. But it's, it's tough. And why is it so hard? Why do we fail at doing this? So the question is why, why does agile fail in some organizations? And how do we get how do we get around those pitfalls?

Unknown Speaker : 4:34

Yeah, that's a, that's a, that's a big question. And it gets to a lot of, we'll talk about a number of different things, right. I'm gonna have to do a little bit of a setup for some of the premise of it, but I'll give you the cliff notes version. The short answer to why does agile fail in enterprises is dependencies. That is the short answer. Okay, right. And has to do with all kinds of dependencies dependencies, of teams of silos of

Unknown Speaker : 5:08

the flow of work, dependencies of technology, dependencies of

Unknown Speaker : 5:16

leadership, even, like, what are we willing to enable and secure? So that's that's kind of the short view is, is it's, it's all about the dependencies. If you think of an agile transformation, right, let's, let's kind of understand a few basics first. And let's get we'll work our way back into that answer. Right. So when you read the book, write the book in air quotes around that for agile, right? And it talks about agile teams. You maybe you went out you got your certified Scrum Master certification from Scrum Alliance. They're talking about an agile team, a small group of people who are cross functional in nature. They have all the skills and capabilities required within that team to deliver on their mission.

Unknown Speaker : 6:14

interpret this, right? They have to guess.

Unknown Speaker : 6:19

That's it, you're done. Right now. That's the idea that two pizza team, right? It's if a team takes. If it takes more than two pizzas to feed a team at lunch, then the team's too big. Right? Because small teams are more effective. Think about about you navigating a large crowd like you went to a sporting event. And you're leaving the you know, the games ended the home team one everyone's super excited. Everyone stayed till the very end, and we're walking out the door, right? Like it's just a bunch of people and it's hard to get through that. If you're by yourself. You can move quickly. Right, because you can pivot fast you're making decisions for just yourself moves easily. You're with your whole family. It takes more coordination, right? Yeah. You know, is there's five you, your wife, three kids and you're walking through. Yeah, you can do it. But you've got to have communication and coordination, but it's possible.

Unknown Speaker : 7:19

But it's with like, I prefer I prefer to travel alone for that very reason. I know

Unknown Speaker : 7:25

right now that's exactly like I I can navigate airports very well. And it drives me crazy doing it with anybody else. Just because yeah. Yeah, for sure. Now that you're saying thing, like if you went on a school field trip, and there are four classes that went to this thing together, trying to leave that stadium in a coordinated fashion where we don't lose anybody. Is takes a lot of work, right? We it takes orchestration of people communication and, and and it's just harder to do so when they tell Talk about agility. That's why you hear this to pizza team kind of as a size because once you get bigger, it just takes a whole lot more work to coordinate effort, right? Yeah, so, so teams, you know, are foundational part of agile and from my own background like me, like the fundamental cherry on the tree of agile, right? What is the fruit that we're going for? is being a part of a great team? Right, like a team that I want to come to work for where we, where we support each other help each other back and yet we have difficult conversations, right? We have the freedom that I can, you know, you can say, Hey, I don't think that idea is a good one. And here's why. And we can have that productive debate, you know, and still go hang out and throw darts and you know, be friends, right? Like, I have a lot of friends from teams I work on because they were just great teams, great people like I want I want to create that everywhere. So when we think about That agile team, right? There's, you know, there's typical in a transformation, you got some different approaches, right? If you're if you're a small company, you know, and you're getting started, you're a startup, you naturally kind of have to work that way. Because that's just the way you were born, right? Your company was born as a small thing, we got a start up or an idea. We're gonna go make stuff, we're naturally a small team. But if you're, if you've grown to any size, then you have to think about work and out workflows. And sometimes, in companies that have been around for a long time, some companies that's decades some companies that's a century, right, they've got established stuff, right? For reasons right or wrong. They've come to be who they are, because of history. Right? And that's, that's it. So a lot of times a company will go we've got to be better, right? Whatever better means sometimes better means faster, sometimes better, cheaper, sometimes better means happier people. Right? You know There's all kinds of definitions of better. So we've got a company and there's some business drive for, for us to be better. Then we're looking at you know, a lot of companies are looking at agility because it's about how do we deliver things in a better way for our business. So there's different approaches you'll see in a transformation. You've got a practice lead, right? Like, like, let's just go do Scrum. Right. I read the book. It says it talks about these five ceremonies and things and let's just do those ceremonies. And that'll that'll help make us better. Right, that's agile. Yeah. Okay. Sure. Some companies approach it from a culture perspective, like, we just need the right culture, like we just need the right way of being and and then we will be better. And then some companies approach it transformation from a structural perspective, like, we've got to set up the conditions in order for those things, you know, to happen. And and the answer is all like, all Have those are required? You know, you can't, you cannot just restructure people to think about the flow and make small teams that are encapsulated for value and everything else just happens magically, right? You still have to have a way of acting of doing. And that's practices lead. So you've got to have practices, you've got to have this structure. And you've got to support it with the culture that you want to end up looking like. Like, what do we what do we end up looking like at the end of the day? That's our cultural led transformation. Yeah. So what would you when you talk about practices, what are some of the what are some examples? What's a practice? So Scrum, right, just as you know, as an example of of teams working in an agile way, those are things like we prioritize a we create a backlog of work, and we have a prioritized list of things that we know that we want to build. We do small short increments of planning together, right. We commit to a sprint a short two week time interval, where we look at, we're going to deliver this or these things in that timeframe.

Unknown Speaker : 12:09

And get them into the hands of our users. So we get return on that value more quickly. Right? Where do we short sprint cycle planning together, we meet daily, right? We have daily stand ups to commit to each other as a team about how we're progressing, we want to serve as blockers make sure that those get removed. We want to demonstrate value of our work at the end of the sprint. And we want to pause and reflect on the way that we work inspect and adapt so that we get better do retrospective. So there's, there's kind of five basic ceremonies of, of Scrum, that are about agility about inspecting and adapting and continuous improvement and showing value right? value to the customer. Well, that sort of practices but approaches the stuff we do, right? So those three, three

Unknown Speaker : 12:55

things, you're talking about three variables. So we've got the structure, we've got practices, we've got culture,

Unknown Speaker : 13:00

Yeah, okay. Yeah, exactly. Right. So

Unknown Speaker : 13:06

our point of view that we've shared with Amway is that we start from a structure point of view, right? Because it takes work and it takes sometimes it beyond the authority of the team, if you will, to say, this is how we ought to align our organization in order to deliver value, right teams typically don't have the power to kind of self organize and go, yep, hey, you know, all your senior leadership folks, this we're gonna, we're just gonna work this way. I hope that's alright with you. You know, you've got to have some buy in to be able to do that. So it's important that we, we recognize those inhibitors and help support that and align the organization to work in a in a particular way. And that's why we have our portfolios set up the way we do. We've got portfolio teams helping understand and elaborate the value that We're trying to realize the goals we're trying to achieve our product teams who helped to, to break that, those goals down into the capabilities we have to build or enable for us and our delivery teams who helped to break that down into the small, consumable bite sized pieces of work that we deliver regularly and frequently to get value for our users. Right. That's the structural approach. And the way that we work is our practices. And we support that with a cultural mindset that you hear around, you know, oftentimes, you'll have servant leadership, about facilitating and enabling rather than command and control, right, those those kinds of things are all part of the transformation picture. Right? Okay, cool.

Unknown Speaker : 14:42

Yeah, that sounds good. So I'm thinking about the structure piece as like, what how teams organized, what skill sets they have, what they work on how they prioritize those things. It's really easy in that small startup when it's one group, but the moment you get into any size of scale, any type of scale, you've got other teams that are totally outside of your your purview, your authority to be able to influence how they prioritize how they interact with you and flow work back and forth. And so right away, right away, I see the problem when you're trying to implement agile, or be agile in an organization that is large, you're gonna run into those problems of it can work on a team really effectively. But the moment I try to scale and bring independent other groups, it's that's when it gets tough. Right?

Unknown Speaker : 15:25

Yeah. And it often takes them. I don't like this word, but it just popped in my head intervention, you know, just to break the organization apart and set it up the way you want, right, so that we can encapsulate our teams a little better. Because just like, just like an individual leaving that ballpark, right, our team is the individual unit of value. So we want them to be able to navigate the crowd of work and to be able to move as efficiently and effectively as possible together. Right.

Unknown Speaker : 15:59

Yeah. Okay, all right. So yeah. Okay. So that's our three things. Yeah, I think why agile fails with those. Yeah.

Unknown Speaker : 16:09

Those one, a couple more little foundational pieces here. So if we look at any agile approach, right, there's different methodologies or frameworks that are set up. So you can look at Scrum. There's disciplined agile delivery at scale, you know, large scale Scrum, scaled agile framework. You've got Kanban teams, you've got

Unknown Speaker : 16:30

XP, all these different ways, so many, so many different things under the umbrella.

Unknown Speaker : 16:36

They boil down to really only three things right. And those three things are teams, the team is that is the essence that capsulated unit of agile, backlogs, right the set of stuff that is prioritized and is important for us to go and build for our company to serve to achieve our goal. And the third thing is working tested software right or if You're not a software delivery team, it's working tested stuff. If you're a marketing team, then then you're working tested thing is probably a campaign. Right? A marketing campaign, right? If you're, if you're a finance team, then you know you're working testing might be a balanced ledger, right kind of view, right? But what that means is a set of done. So as a team, we understand our purpose. We have a prioritized a well elaborated set of things that we need to achieve, to help our business that's the backlog. And we understand what it means to be done. Right? How do we get to done and that understanding of done helps us to focus on that goal and to try to achieve that in a short timeframe as possible in iterative and an incremental way. That's foundational, right iterative and incremental and inspecting and adapting or foundational agile principles. So teams backlogs, working, tested stuff, right done. And the work that it takes to get to those, right? So teams means I understand what the value is, or, you know, the purpose that this these group of people exist. And they have the skills and capabilities with in that team to deliver on their purpose. So I don't need to go and get QA from somewhere else, right. Like we have the ability to evaluate whether or not we're done within our own team,

Unknown Speaker : 18:32

right. You know, if they were, if I had a, if I had a team that was

Unknown Speaker : 18:40

serving our end users right there, like a help desk, kind of a team, you know, a skill that you might need within that team is like content authorship, right? Like helping to build the support documentation or your the scripts that we use to help when people call in, right, I might need a content author within that team to Make sure that we're building out the library of things that we provide to make our service. A better service.

Unknown Speaker : 19:06

Okay.

Unknown Speaker : 19:07

Yeah. So teams backlogs, working testing stuff, those are like the no matter what agile framework or methodology that you look at. It's all about those three things. And that scale like as we get beyond a single team having to work together because right, we get we build complicated stuff, right? We're not, we're not we're not a little startup. Simple thing, right? Even, even though startups that have grown, you know, Facebook was once upon a startup, Amazon was one Spartan startup, you know, there's lots of really big companies now, that were startups as they grow. at scale. You have to think about the structure, the organization that will put together of those teams and how workflows through them, where we build dependencies, the workflow, how it flows, like, you know, what do we do to elaborate thing that's kind of like the discount Every side and the delivery side, sometimes you'll hear that as you know, we want to building the right work and building it the right way. Right. Like, I did not say that the right way at all. It's focusing on I could, you know, it's been a three day weekend. And so sometimes the brain doesn't go out there.

Unknown Speaker : 20:23

Yeah, I think I think building the right thing building it right. And what's the third one? fast?

Unknown Speaker : 20:30

Yeah, right. Yeah, exactly. So. So we need that we need to think about the way the workflow so we can focus on understanding what are the right things to build. There we go. What are the right things for us to focus on the most important that deliver the most amount of value when the faster the fastest amount of time the shortest amount of feedback, right? Like, I could think of something really valuable, but I don't want to spend a year doing that building that out because I don't get any return during that time. Like how do I provide some thing of value sooner rather than later because I get much better return on capitalizing that return on my investment, in fact, right? So I want to do things iterative and incremental way, because it just makes good business sense. So we think about how that workflow is for discovery. And then the other thing, right, so structure and flow of work, and metrics, like how do we assess whether we're building the right things? like are we are we getting feedback from our users? Right? Are we understanding our, you know, through adoption of Ozzy metrics, adoption, user satisfaction, right? Are we performing well as an organization? What's our cycle time? How long does it take us to make something ready? How long does it take us to execute? Right? Are we reducing those cycle times to improve the flow through our system, right, so so that's Agilent scale. So eight in basic piece loose, backlogs, working tested software, and at scale structure of the organization, workflow, the way the workflows to the organization and the metrics, how do we, how do we use those things to inspect and adapt and improve on? Okay? So, back to why does it fail, right? It fails in the face of not recognizing any one of those components right as a dependency, and doing the work necessary to remove them, like the work of the transformation is a transformed organization. And in order to do that, we have to remove those dependencies that exist that gets in the way of us creating teams, creating well structured well defined backlogs, creating working tests and software, right like to be really agile, like a startup to be startup like at scale means you can't have teams that wait for each other To deliver pieces of software, right? They've got to have ways that can get to done and tested with a high degree of confidence in very short timeframes without waiting for this other team to do their thing,

Unknown Speaker : 23:14

right? They've got to write like a continuous flow. So there's no Stampede.

Unknown Speaker : 23:20

Yeah, continuous flow. So that's where you'll get like, a lot of technical practice. If you're building software. It's a lot of technical practices, DevOps, continuous integration, continuous deployment, right? automated testing, right? micro services, stubbed interfaces, you know, all all that kind of stuff. Those technical foundations are things that we have to address to have a high degree of agility within those teams. That make sense.

Unknown Speaker : 23:53

Yeah, I think so. There's a lot of pieces. We've talked about it, we'll talk about the structure of the practices. culture. We've talked about teams, backlogs, working tested software, dependencies, different methods for those things. And if I kind of run that back to why agile fails, what I'm hearing is that we're looking at, you know why agile fails as a question about at scale, not a question of does it work on a team, right? It doesn't work in a big organization. And to me, it feels like we're looking at the the people involved, the the products, the work, the things they're building, and how they're doing it. And when you put all those together, I kind of picture it as the work from taking an idea or feedback from a customer and moving that to something that we've now put out into the market and gotten value for it a return on our investment. We want to shorten that cycle and make sure that we're hitting all those points, getting the feedback, improving it and delivering it with a continuous flow, not not a kind of update. apart you wait, then we'll ship it and then you build apart and you wait. Like there's this just kind of smooth flow. But probably I'm guessing that it feels really clunky. When you go from the old way of dependent and waiting type of scenarios, to a continuous flow and agile organization. There's probably some clunky middle ground where you're kind of in the middle of a transformation. And it feels like what the heck, why isn't this working? This feels broken? Almost because it's not the old and it's not the new. It's somewhere in between?

Unknown Speaker : 25:32

Yeah, there is. It's a great point because there are the sounds funny for some of my my agile lists and industry. There are degrees of agility that may or may not be appropriate, right? Like, if you think about a startup example, right, they necessarily have to go fast and get really quick returns. feedback on what they've done. Because they're learning and exploring in the market. Right? They don't know, they have an idea, but they don't know what's going to really resonate. And so they're doing lots of little tests. Right? Yeah, I'm gonna put this thing out what if I do this? You know, they might do a B testing to say, I don't know, if if, you know, this kind of color scheme resonates better than this kind of color scheme. Let's find out. Let's get data. Right. So those kinds of companies are being very, are in an emergent market space, right? They're trying to learn what's happening, and they're having to adapt very quickly. Right? And that's a very different scenario than say, if you're running a bank, right, if you're running a bank, you do not want your bank balances or your customers statements to be adaptive and iterative. It should be right Yeah,

Unknown Speaker : 27:00

you know, I can't

Unknown Speaker : 27:02

think of the picture in the bank situation, there are parts of the bank that are rigid and need to be structured and very predictable. And there are parts of the bank where we want to be incremental and adaptive and an iterative, you know, like, think about the features and functionality of banking apps. I mean, in the last five, six years, like it's just proliferated, and banking apps have come out with all sorts of new things. And so I could see in a bank scenario, both of those be necessary. So some teams needing to be really agile, some teams not. So is that stripe? It's also true. So we had to look at our organization and assess which teams need to be to what degree of agility?

Unknown Speaker : 27:43

That's right. That's right. And so that's where we, we've talked about this where we have different base camps because we lay kind of these levels of agility against this quadrant to view about emergent or convergent right Like the back end of a bank, the ledger and the actual transactions, we know what that wants to look like, we were not trying to innovate that space, right? You know, credits in debits out, right? That's way worse. Yeah. So there's an adaptive or convergent, you know, kind of a view, excuse me emergent or a convergent kind of view. And then the other axis of that kind of view, is this predictive or adaptive, and that's like how our, our organization needs to react. So there's the market itself, emergent or convergent. And the organization how we have to react which is predictive, like I need to be able to depend on this level of stuff getting done, or I need to be able to pivot very quickly because I'm learning You know, I'm testing in the market, right? So that, that back end of that the bank, or any company's ledger, financial ledger, right. We want the work to be very predictive, and we know what needs to be Done brilliantly convergent, right, the front end of the bank, like you said, they're learning and testing, right and responding to that what makes sense for customers what they find value in, that's adaptive, and emergent?

Unknown Speaker : 29:13

Well, as you're describing this, I think, I'm trying to think of an example of a company that would be all one or the other.

Unknown Speaker : 29:20

And I can't,

Unknown Speaker : 29:22

I think it would require me to look at what capabilities does that company offer and which are the predictable or convergent versus the adaptive and emergent, because it's like the different the different parts of a business need to operate differently, but somehow work together in a cohesive system. Especially in really large companies. So anyways,

Unknown Speaker : 29:48

anybody in a in a digital sense, right any any company working in a digital environment, is gonna have multitudes of have different levels of agility to you that they need in their life. Yeah, I haven't I have a neighbor. And he is his. He's an executive at a company construction company, not just like a little one, but they build like highways, right? Like, major, major kinds of things. And there's big big projects, multi year, multi billion dollar, you know, kinds of projects. They, they did, they did work in in Dallas recently where they were revising the existing main loop around that around that city. And you have to have traffic that flows all throughout that you can't just stop and go, Hey, guys, this is gonna be closed today, but it will be back open probably next week. Right? You're not iterating on a road. So for them there they had they must be very predictive. And they must be very convergent in terms of their methods. Right. So we have we have interesting debates about you know, levels of agility there, so

Unknown Speaker : 30:56

yeah, how much I need to do up front.

Unknown Speaker : 30:58

Yeah, yeah, they have to do Big upfront plan because they're gonna show that they've got they can have continuous traffic flow with minimal disruption throughout the whole thing. And they've got to be able to hit their marks. Right. There's certainly they built in financial incentives in their contracts to do that kind of thing. Because the the municipality doesn't want to have they can't afford unlimited budget, right? They got they have to know how much I'm spending,

Unknown Speaker : 31:25

right? Because we're paying for stuff. Right and taxpayers gonna put the menu.

Unknown Speaker : 31:29

That's right, exactly. So. So that's a very different kind of environment. You know, at Amway, we've got multiple kinds of environments to you know, you've got, you've got financial ledger, right, you've got your, your sort of customer data aspects as well, right. You're not iterating usually on customer data, right? You need to know who your customers are. You need to know how much they've spent right? You need to know As we're building products, we need to be able to count on our supply chains. Right? Those are those are more convergent and predictive kinds of things. Whereas some of the new things that we're working on for, you know, your a 70 vision, or the Amway growth plan kinds of things, where we're thinking about like social selling, or we're doing virtual apps to have customers sort of get a try and buy kind of experience, those kinds of things are more adaptive and emergent, right. Yeah. So the whole point, the whole point of that was because a big failure mode, why why companies fail, sometimes they they do not recognize the level of agility at which they need to operate. Right? Yeah. I certainly even in my own transformation experience. There was a group I was working with and they were building like a like at the corporate web page, intranet, right for all employees, everything to use. And I was a small team. They were fantastic. we iterated we learned we got data was great. I was working with another group. And they were, they were the financial ledger group and a big SAP implementation. And this was like, it was really difficult, you know, because they could not adapt. Right? So we, we had to decide what was the appropriate level of agility that we required, and to set teams up to be successful in that environment. Like that is the work right. So as an organization, we need to recognize what level of agility we really need to achieve our business goals, and to support our teams in their development of their skills and practices and the way the organization works back to teams backlogs, working tested stuff, at scale, the structure of the workflow on the metrics, in order to support the level of agility we need, in that in that sense. situation.

Unknown Speaker : 34:01

Okay, so I'm trying to think about how

Unknown Speaker : 34:05

so this kind of the comment was, your comment was that one of our common modes of failure is not recognizing what level of agility we need. How would you know a person or a group of people not realizing that there are different levels of agility? And that even within your own organization, you will have varying levels of agility. I know I can think of some people right off the top of my head, some very high ranking people who are thinking of this as you're either agile or you're not. And I want everybody to be agile, the whole company to be agile. But we know that's not the case. We know that's not how it works. So once the kind of fall I'm trying to follow the logic of someone doesn't recognize the varying degrees of agility, how does that lead us to failure.

Unknown Speaker : 34:54

So

Unknown Speaker : 34:57

for a group if you're trying to be First of all, when we say we're trying to be an agile organization, right, the foundations of that are iterative and incremental, and inspect and adapt, right? Like that's, that's what we're trying to get to to learn. So if we're trying to have a group who is probably more predictive and convergent by design, and we're thinking that they need to be like a Lean Startup kind of a group, then we're failing to recognize the level of planning that they may require, right? Like, like when you have dependencies between teams. You've got to manage those dependencies. You've got to understand them. You've got to schedule work accordingly to recognize those dependencies, etc. Like, right so we're leaving the stadium and we've got that that three, you know, three classrooms worth of people, right. We've got to make sure the buses there at the right time. We got to make sure people meet in the right spot, right? We cannot be waiting. You know, while some people may have decided to all, you know, go to go to the bathroom, right or buy to buy the T shirt, right if you if you want, if that's a goal, if that's the thing that has to happen, we've got a schedule that we've got to recognize that and schedule that and build that time into the plan. So because so that everyone arrives at the destination at the same time,

Unknown Speaker : 36:24

otherwise, you miss the headcount. And you screw up the whole departure process. Right?

Unknown Speaker : 36:28

Yeah. And you do not want to get the call from you know, Mrs. Smith, because Little Timmy got laughed by a teacher. Right?

Unknown Speaker : 36:38

Yeah. So when you see how I can see how in some of the, like some of those more convergent and predictive scenarios if you really push that team to try agile practices, and they said, Yes, want to try it, and they do it. You might actually make more of a mess than if you had done it in a way that you had already been doing.

Unknown Speaker : 36:58

Yeah, we want to Take, we want to take those I mean, dependencies exist, right? And companies that are that are on agile transformation, have those in their organization, whether they're structural, whether they're technological, whether they're about the understanding the work, the backlogs, whether they're you know, about working tested software, right, there are dependencies. And so we want to set up and recognize those and, and help them deal with them. So getting to higher levels of agility, so to speak, becoming that Lean Startup kind of organization is all about recognizing and breaking those dependencies that we can break. Some of them we can't write like big financial systems, right? You've got to have heavy testing periods. Right? Because you don't you cannot accept the risk that something breaks.

Unknown Speaker : 37:53

Yes, we can only be as adaptive or as fast or as just agile as the The

Unknown Speaker : 38:01

slowest or the most strict dependency that we have, right? The weakest link in the chain is the one that we're all going to default to.

Unknown Speaker : 38:13

Yeah, so where are those exist? I'll modify that just a little bit. Because if you have, if you have applications or systems that that use that data, for example, then what we want to do is to try to encapsulate that dependency as much as possible, so that those other teams can move faster on their own. So that's why you need to set up with the services we're in and, you know, architecture or lots of little micro services, so that those teams can be more flexible, and not have to make changes in lockstep with that finance system,

Unknown Speaker : 38:48

right, right. Okay. Okay. Okay, so there are ways to break those dependencies where we have them or at least manage them away that allows other other groups that are dependent to keep moving

Unknown Speaker : 39:00

That's right. That's right. Yeah, you got to but it's, it's recognizing them and encapsulating them so that others who need to, can move more quickly.

Unknown Speaker : 39:07

Yeah. And I can see how if we tried to do what we were describing before, where you're trying to push agility into an organization that isn't built for an adaptable or emergent space, it's gonna feel yucky for the people involved, the results might not be optimal. And then you're going to get, you know, team members leadership, all your stakeholders are going to look and say, this sucks. What this agile thing doesn't work.

Unknown Speaker : 39:33

Why, why are we doing this? This is broken.

Unknown Speaker : 39:35

And it's because we've applied it in the wrong situation.

Unknown Speaker : 39:39

Exactly. or expected. This will sound funny, we expected too much too soon. Because as a as an organization who has all of this history, all of this stuff, right? Everybody's got them. Saying that we want to Yeah, we aren't we should be like lean startup all over the place, everyone being, you know, really like this startup mentality. You don't just move from zero to 100 miles an hour, instantly. There's actually some, as you've talked about in some of your videos, there's an intentional progression of capability, right, which we call the base camps. So the very first job that we have to do is to have a stable and predictable organization, right? Like if you walked into a manufacturing line, and all heck was breaking loose, right? You're making products and there's quality problems. We're not Six Sigma, you know, we can't depend on how soon we make product. We don't know how long the first thing you're going to do in that manufacturing line is stabilize it, because any change you make, right this is what did we learn at like in seventh grade or something like that, like, you know, the the foundation of high of a hypothesis and right, you've got to formulate your hypothesis. You've got to conduct your experiment. Look at the results and And you know, there's Mrs. You know, Mrs. Doolittle or whoever it was gonna be mad. I don't remember the five steps of that. Transcribed by https://otter.ai