Lean-ing into Agile and DevOps

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your host, Dave Shark. I'm Peter Madison.

Peter, great to see you again, talk to you again. What are we talking about this week?

Well, I thought it might be fun to unpack a little bit of lean thinking, essentially. And uh I I originally had this quip in my head around leaning into Agile and DevOps, and uh it's been sitting in the back of my mind for a while. And I thought it might be fun to like unpack that and have a have a chat.

Yeah, it's I I it's an interesting one. Whenever we're talking, when I'm talking to Scrum Masters or coaches in an organization, there's the sort of change agents in organizations. I'll often refer to the fact that after you kind of got the hang of whatever framework and methodology and change that is being adapted. So over the next one or two years, as people stabilize that and get really, really good at what it is they're doing, uh I'll mention that at that point you're going to start finding you read about lean all the time. You dig into it. It's it's the bedrock on which everything is really I was I was gonna say it's like meeting Gandalf. You've got the rest of the group coming through, and every time I bump into an expert in lean who really understands it, it's a little bit like, okay, I'm gonna shut up now and listen and understand it and figure out how that impacts the change that we're working on.

Yeah, I and you're right. I mean, a lot of the practices, a lot of the things that uh we see are based off lean, they bring in lean principles and understanding uh the lean practices around removing waste uh and I well identifying and removing waste is uh is critical to help to understand like how do we help the system improve? It's uh how do we look at uh even like fundamentals like uh work in progress and overburdening of the system and things like this all come from lean and then are applied into other agile practices like uh Kanban and other places. So um it's it is very much the root of a lot of the things that we talk about when we talk about these modern ways of working.

Well, it's it's that it they provide that terminology in the framework. It's a little bit like you know, um, as we're as we learn how our systems work and how the processes and how we can make that more um uh more effective for what we're trying to achieve. What I kind of go back to lean for is to add the layers of the language to describe what we're looking at. And whether we start with something like value stream mapping or we start with just simple things like identifying constraints and using theory of constraints to try and figure things out, all of these eventually go back to some of the core principles behind lean, behind the Toyota production system, that are powerful, they still have relevance in what we're trying to do, even though in many cases it's digital, it's virtual, the the it is is a different space, but there are lots of aspects of lean that translate into it. But that also leans there are aspects that don't translate over.

There are. There are different ways in which it can be applied. And a lot of what lean is looking to do by removing the waste from the system, some of that waste we might actually want in the system. We uh there are certain aspects where we we want the opportunities to learn in the system, which means that we don't want to remove everything from it, because then if we remove that, if we remove too much slack from the system, then we'll find ourselves in a situation where we'll stop innovating. And a lot of what we do in like complex knowledge work is very much based in we need to innovate, we need to have the opportunity to experiment, we need to be able to investigate different directions and ways of going. And if we remove all the waste from the system, we may prevent ourselves from being able to do that.

Yeah, I'm I I contest a little bit. I don't think it's that you you'll stop innovating, you're innovating in a very narrow space, which is how we're trying to get things delivered, right? But I think uh one of the things that we both of us have recognized is a lot of the organizations we're working with, in fact, all of them in today's world. And um, there's a just a fantastic uh video by Gary Hamill, which talks about, and it's quite an old video now, but he talks about how uh we're living in a world where exponential change is all around us. And that exponential change creates complex environments, and complex environments are not the environments where you want to strip out all the variation in the processes, the way that you're dealing with, because that variation gives us resilience, allows us to modify our behavior and shift and change based on what's happening around us. So there is on the one, and this is where we get tied up with things like Six Sigma, lean Six Sigma, that that whole focus on efficiency and using value streams to remove that waste and get as efficient as possible. We need to remember the goal is not to become as efficient as possible. There's definitely wastes we can get rid of, but we, as you said, you need Slack to handle variation. You need Slack to be able to uh to be resilient to the change, which we don't control, which is happening all around us.

Yeah, you see this a lot in uh in DevOps practices too. It's a understanding that sometimes the right thing to do is to have duplicate paths through things. Uh, that by if you can if you combine things too much, you end up with contention. Because it's uh so it looks great on the financial books, but it looks really, really poor in practice when you try to operationally run it. So we we've got to create this balance between the two and understand what are we actually optimizing for here.

This it just reminds me as you're talking about that, all those conversations, and of course nowadays everything's in the cloud, it's a different piece, but back in the day when every organization uh of any scale had its own data center, and the realization dawning on organizations that they don't need one data center, they need two because they need some resilience to being completely dependent on one building with whatever that might be, one location, one and that that's that whole piece of there's a balance. It's like anything, there's a continuum between super efficient, which um our supply chains, for example, globalization in the last number of decades has really changed what's there. But then when you look at things like the toilet paper scenarios from a year ago, or you look at some of the blockages within these highly efficient supply chains, which are already predicting that Christmas is going to be a little bit barren for certain parts of the world because the products aren't shifting the way they're used to, and they don't have the resilience of additional pathways to get that product to market.

Because we've uh over time we've reduced the variance by putting out bigger and bigger container ships with more and more containers on them, and now if those ships can't fill up with ship, then all of a sudden everything starts to crumble, and uh yeah, the the cost of putting something in a container and shipping it across the ocean has skyrocketed. So you've but at the same time it's this is that optimization for efficiency in this kind of the so the which means that's what you're looking for.

Yeah, I and and what I what I think um a lot of the conversation where lean sort of comes to the table as we're looking at an agile transformation, as we're looking at introducing DevOps into um an organization is it allows us to get our thinking away from what's right in front of us. And I'm thinking here of um you know Mary Poppendick's book on on soft lean software development and the the application of lean disciplines into the digital space of digital product development or product development, I guess, in in today's world. I I what I really appreciate about that is there are some fantastic, well um like really clear um doctrines, if you like, whether it's building quality, delivering fast, deferring a commitment, all of these sort of favorite little lean disciplines that we draw down on, which have huge value in understanding what we're doing and invariably are not front and center in the way our product development processes have been put together, have come together. And uh I think those lean disciplines change the conversation, allow us to start looking across silos in the organization, that allow us to look upstream and downstream and begin thinking a little bit more about everything that's going on beyond the area that we are working in.

And that systems thinking approach is is really essential to start to understand what are the other things that are impacting what it is I'm trying to get done. If I have to expand it and understand that I I work within a system that's within a system, within a system, which is I'm looking at all the different interactions between these different pieces. And so there was another piece that we were talking about when we were touching on the Six Sigma there, and Six Sigma is a process to reduce variance and improve efficiency. And uh that so it's it's very good when that's what you need to do. Uh, but when we're working within a uh in a complex environment and uh a complex adaptive system, and if we're working inside of uh those types of environments as we typically are within knowledge work and especially within uh software development, uh then we it's it's not really the right practice to be applying to that, because we're not really looking to reduce variance, um, at least not on the uh the inputs, right? We're not looking to reduce variance on the inputs to the system.

I I mean it's it it's a really interesting context because um the the concept of lean six sigma of that values understanding the value streaming and eliminating variance as we're building that. That is so that I can repeatedly get the same result over and over again. And it is and as quickly as possible for as high a quality as possible. The interesting thing is there's a primary assumption there is that we can really like there's a stable environment within which we're able to do that. And we're able to make sure that uh, you know, if we're getting a truck delivering parts from A to B, that they can predictably get the parts from A to B in a time frame that we somehow control. What's interesting is as you add more complexity, you actually a great example is cues. I mean, generally we want to get rid of cues, but actually cues allow that buffer. If those parts don't get from A to B in the time frame, but we have a queue of those parts, we can still keep delivering. But if we don't have a queue, then that supply chain grinds to a halt. So the fragility that eliminating the variance brings to the table is only really apparent when there's change in there. And of course, complex environments are all about change. I mean, change itself is changing, it's continual. And that means that we need a bit more, a few more buffers, a few a bit more variance in that system to be resilient to that change.

Yeah, no, and we we know where those buffers exist when we talk about it from a computing system perspective. We have queuing mechanisms that exist between services that we that we run so that we can understand and we have caching systems, and although, of course, is the the the classic grow uh um joke about the two hardest things in IT being naming and caching, or some variant of that. I mean, there's many variants of it. Uh there so when we look at an organization that's delivering, how do we introduce those buffers into the way that teams and individuals are interacting with each other?

Yeah, it's so here's one of the first things that's good that really is it goes against the grain is have spare people around, right? I love when when we've um there's a great uh video, and we're all familiar with this one, I'm sure, at this point, but if you've not seen it, you absolutely have to see it, and we'll put it in the link about um tracking uh watching uh a group of individuals bouncing a ball backwards and forwards. And I'm not going to tell you what the outcome is because if you've not, if you don't immediately think of what I'm thinking of in the back of my mind, you want to count the number of balls being passed backwards and forwards between a group of six or seven people. As a result of that, something will happen and you either see it or you don't. What's interesting in that particular video is the studies show about 16%, something like that, 16-18% of the population will see the distraction. The rest of the population do not see that distraction. So, just one key thing is having those that percentage of people who see things in a different way in your organization is really powerful because they see things differently. They can they can um behave in a different way. And this is the the little mavericks. That's the people who you know get involved in the projects that don't quite go anywhere but are very, very peculiar. And and so much now is focused on utilization, on the efficiency. We're reducing the amount of headcount, and we're driven by this need to be able to account for everyone there. We want these pockets of parts of the organization where there is unusual activities going on. I mean legal, beneficial, unusual activities, not Enron, right? Um, and you want you want uh parts of that organization where the people that think differently, that challenge the status quo. And now you can start, you know, when we're only tightly focused on one thing, we're missing the opportunity to have different voices in the room, to have different perspectives of what we're seeing. That's one of the places where I would start. And I think in many ways, it's been an area that a lot of organizations are kind of winnowing out some of these really influential voices.

I think there's two elements to that. There's one element is that uh we see this at every layer of the order, it's a very fractal piece. It's like whenever we have a group of people come together at whatever level in the organization they are, um, people will uh will tend to gravitate and bring in other people who are like them, and they will tend to work with them uh in that way, and bringing somebody who doesn't think the way that you do to the table and making them a part of the group so that you have the the opportunity for that that almost conflicting voice, the healthy conflict of uh conversation around what it is that could happen or where we might want to go, what outcomes we're looking for. Uh, that that's absolutely critical. And we we see this a lot uh in organizations, and uh you you see it a lot too, um especially when you have the the sales personality and the engineering personality and the two uh because the the these stereotypically will tend to have very certain types of personality and they won't necessarily always get along, but when you put them in a room together, um and uh which is a good thing to do, is start to get an understanding of like what each other's needs are, uh, that's when you can start to get some really interesting insights and really start to see how things are working.

I think uh I mean as that that's looking maybe at the people side of it. I think part of the other side is understanding the impact of metrics in an organization. And uh just a couple of ideas that come to mind. One of the key metrics that we'll often look into in a product development pipeline is the discard rate, the number of ideas that are generated, pursued, and then a decision is made to drop those off. And in some organizations, when we start talking about, you know, which partially complete projects or partially complete changes to your system are suddenly paused and stopped, not because your budget runs out, not because it's the end of the financial year or the team is captured and taken over to a different part of the program, part of the organization, but because a decision is reached, hold on, this isn't the most valuable thing. Actually, we're we're part way through, 40-50% through, but we're not getting the results we expect to see. We need to pull the plug on this and use that somewhere else. So that discard rate, that you know, when do you pull the plug on things? There are so many organizations that pride themselves on a hundred percent completion of what they start, or a hundred percent completion of you know their their annual operating budget and the commitments that are made there, which is commendable in certain ways of looking at it. But in an environment which is changing all the time, what you actually want to see is a hit rate that is less than 100%, because it's being modified as changes happen around the organization.

I think I think that's a that's a very good point. And it's it's one a lot of organizations miss. It's the it also comes into that fear of rework as well. It's this fear of, hey, I've got this far down, and uh uh I'm I don't want to go back and have to redo all of that. I mean, that's all of that work, but and discounting all of the learning that was done during that to get you to that point. Uh but being able to make that decision about okay, this is this is as far as we can take this, we have to shelve this. And uh so there's I I think we've covered a lot of good ground here uh in this piece. So thank you for indulging me in this topic of conversation. Uh the uh we we we've gone through the uh the efficiency effectiveness uh topics, um we've talked a bit about Six Sigma and uh system variance. Uh so what would you add to that to sum all this up?

So uh let me add two things that we kind of closed out on, uh as well as the points that you made. One is the value in things like looking at lean disciplines and you know, really driven by Mary Poppendiek's uh work as well, but it's been built on as well in in the last few years as well. And then secondly, is perhaps understanding that organizations need variance, Slack, something in the system that allows them to stay resilient as a whole. And we talked about two key areas. One is keeping those mavericks, those people who challenge the status quo in the organization and around and close and involving them in certain parts of the of the process. Uh, and then secondly, is looking at key measures of success, what we look for, and it's it's a little bit like watching out for the things that we are not measuring and maybe bringing those up to view that and see how we're maintaining variance in our organization.

I think we there's also some elements there where we we sometimes fail to quantify what we're looking for in those outcomes, so we don't put numbers around it. So we and we've talked about this before when we've talked about um experimentation, but but for in order for you to determine whether the experiment is a success, to to apply scientific method, you need to be able to collect data and actually measure against something to know whether or not what you're doing is is working. And uh so there's there's that piece, so we we often fail to see that piece being done as well. So so thank you uh for the conversation, Dave, as as always. And uh if anyone would like to reach out, they can find us at feedback@ definitely maybeagile.com. And uh thank you. Thanks again, talk to you soon. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.