Dealing with complex systems

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 hosts Peter Madison and David Sharrock. How are you today, Dave? Excellent. How are you doing, Peter? I'm a little tired, but other than that, I'm I'm good. I'm good.

It's been a very busy week. Well, it's that run-up to Christmas, isn't it? There's a lot of a lot of like interesting things going on. If you think about, we work in in sort of systems thinking and we worry about getting flow in an organization, and yet our busiest time of year, of course, is the last quarter of the financial year, because many of the organizations have hard deadlines around budgets and project deadlines and things like this, which is somewhat counterintuitive to what we're trying to work with organizations on.

It is actually, and I mean that's uh an interesting topic in and of itself. This this we we find ourselves driven by these uh these timelines that are not necessarily within our control, which drive certain behaviors within the organization, uh, and that trickles down uh to us who are trying to help those organizations by having them jam a whole bunch of work into the last quarter of the year. So which works very well. Keep on doing it, we love it. I mean, it's so much fun.

Well, it's it's a difficult one because uh it's I think one of the things that we wanted to talk about today is the difference between taking simple approaches to solving problems in complex systems. And um, as we were kind of teeing up this conversation, we I think both of us see so many conversations where uh where people for very good reasons are focused on optimizing a process or getting the most efficient process they can, and they're looking at a tiny part of a very complex system with uh almost like a one-dimensional view, is the way I think of it. That sort of theory of constraints, there must be a constraint in here. If we find that, we resolve that, then uh you know, hallelujah, we're going to be able to meet our deadlines or timelines, or you know, the organization will work more efficiently as a result.

Yeah, and it's and it's true. I mean, if you if you can in a system find where that bottleneck is and optimize there and only there, then that's great. It's just that within most knowledge systems, uh, which are very highly complex, a lot of parallelized work, uh a lot of moving parts uh going on simultaneously, that constraint is constantly moving. And it may be moving for every item of work that goes through the system. It may be uh and as a as a consequence of that, saying, Okay, I found it, I'm gonna put all of my effort into optimizing there. By the time you actually do anything, you find that, well, actually it's decided to go a different route, and it's what you're doing is not actually having the effect you expected, expected to do. In fact, you were telling a story just before this, which was quite a good example of that.

Um yes, so to fill our listeners in, the the um office where I'm working here in Vancouver, there's a road bridge that's been being rebuilt over the last couple of years. And one of the interesting things is the road bridge goes over. It's a small bridge and it's a small stream that it goes up, um, the bridge goes over. But over the last sort of uh three months, as Vancouver has been inundated, as people will know all across Canada, Vancouver gets a lot of rain, and we've got all of it basically in the last six weeks. And what you can see we send it that way. Yeah, thank thank you very much. Much appreciated. And what you can see is the the um underneath the the bridge, there's a walking path that's been built. There's a number of you know, the edges of the stream have been carved out, and even in the last six weeks, you can already see builders have had to come back, repurpose the pathway, repurpose some of the um the barriers that they had put in place because the volume of water and the positioning of the water in the stream has shifted and is going in places that people were not expecting it to go to. So, for example, right now the under under path, the the cycle lane and walking lane is currently mostly underwater most of the time at this point. And these are this is part of the problem with complex systems, is things don't align nicely with the you know the the rule of the ruled line and the kind of mapped out expectations that we have when we look at something and we go, okay, this is clearly a bottleneck. Let's make this, this, and this change, and everything will resolve itself.

Yeah, and and we we see this, I I agree, I see this time and again. It's this this this belief that I'm gonna be able to find that one silver bullet that's gonna fix all of my problems and everything's going to be absolutely perfect after that. Uh but it makes uh quite a number of assumptions about the nature of the system that you are dealing with, and uh it doesn't take into account that complexity. And the the consequence of that is that uh you you you generally don't end up having the impact you're expecting to have, or it has potentially even a detrimental impact to the overall system, and you end up with even bigger problems uh as a consequence of what you were trying to do. And so we find that it I mean it's much better to start to change the way you think about the system, change the way you you look at it, start to build resiliency into the system, start to understand like how how do I want the system to respond and start to build in some uh different behaviors as well.

Well, I I'd pick up where when you're talking about the start, one of the challenges that we often have is that our our goal when we're looking at a re-org, when we're looking at uh say a product delivery process and we're trying to improve it, is we start with a mindset that we're looking to optimize and make something efficient. And the goal of making something, optimizing something and making it efficient, even though we talk about a learning process, continuous improvement, and all the rest of it, what we really mean is can we kind of fix this, make it efficient, and then forget about it and start benefiting from those efficiencies? And so that often comes through with just the way the problem solving is addressed. You know, we bring a new role in or we define certain procedures, and then we kind of it's done and dusted and we move off. And you see that with other roles suddenly disappearing in an organization because we go, well, hold on, we don't need those roles anymore because we've solved the problem. In a complex adaptive system, you've uh solved a problem today that may resurrect itself very quickly in the future. The example of the shifting stream bed that I just used uh just described um from the bridge outside. And the mindset is has to be less about one about of seeking efficiencies and sort of nailing that to the wall, and more about effective and resilient properties in a system, which is a very different resilient, effective systems have redundancy in them, they have additional roles because you never know when those roles are going to come in. And this is almost exactly the opposite of an optimizing efficiency mindset.

Yes, and and and we we look for there's certain things that we know, and some and some lean principles can help with some of these pieces, but having uh understanding those where we have those buffers, the inventory is the uh where we're we're keeping enough capacity in the system to be able to absorb uh these changes, to absorb the new things that are coming in. Um a lot of uh there's been a lot of press around uh just in time, of course, recently, which has uh been causing a lot of um uh commentary and there's a lot of misunderstanding around that concept and how that uh actually helps systems be uh resilient. It's about the resiliency of the system. It's about it's not about we only need just enough in the system, it's about understanding the system well enough that we can ensure that we have the right amount of things to ensure that the system will be able to operate with the amount of capacity it needs, which is very different from the way that it's often interpreted and has been interpreted in the Yeah, absolutely.

It's it it's that it's that push to have no buffers, which is that efficiency optimization mindset. Whereas what we really want to do is understand where we need buffers to allow resilience in what's happening, and that's a that just that one thing about zero buffer versus what's a buffer that facilitates resilience in the process that we're working on with, and what's a buffer that is wasteful and is actually hiding uh possible defects or or or you know dysfunctions in the process.

Exactly. And I mean, if you look at I mean classic example is um company like uh like Toyota kind of famously brought a lot of this stuff to the forefront. Um but if you look at some of the behaviors that they they've got there, where they if they've got a if it takes tens and tens of thousands of parts to make a car, and they because they've got so much understanding of which parts of their supply chain are necessary, which components are the most critical to that, they know which 500 out of those tens of thousands of parts they need to keep in stock at all times and which one's the most critical. So they identify that, they make sure they've got those, and they ensure that that's available because that adds to the resiliency of the system. That gives them the ability to uh uh they they know that by having that that's going to enable them to be able to uh um respond.

Yeah, and I think um in many ways it's the you know there's a get fixed quick mentality. And I'm just thinking here of uh um theory of constraints. I'm a huge fan of theory of constraints in terms of understanding a process and looking for bottlenecks and how to resolve those bottlenecks. But if the only thing we do is view a process as a single one-dimensional delivery system, value stream, whatever it might be, uh what we're missing is the complexity that goes behind it. So that on the one hand, we need to know about constraints, we need to know about how to work with bottlenecks. But on the other hand, if we think what that means is once we've solved it, the problem has gone away, well, we're not recognizing that it's a continuous monitoring and and a continuous learning and understanding process to always be watching for not only the next bottlenecks, but also the areas where resilience means you don't have one path to solve things. There may be multiple ones. What do you see in organizations? What do you how do you uh um maybe help them understand this or help change that mindset as you talk to different organizations?

Uh so I mean some of the pieces that um one of them is around ensuring that you've got enough capacity. I mean, there's the theoretical approach, right? We we talk and we provide the we provide workshops, we show them like what happens if you have everybody working at 100%, and then that means that there's no capacity for uh and nothing gets done, everything slows down. So we we demonstrate that and we show what that looks like. There's a lot of the the educational side of it from that perspective. Um we we also then uh from a practical perspective look at well, what are we measuring? How are we understanding flow across the system? Are we measuring for the right things? What's the impact of what we're measuring? How well do we understand the system that we work within? And we can use those um metrics as a way of uh saying, okay, if we if we increase capacity, if we reduce the amount of work in process through the system, do we see more stuff occurring? Do we see that we're actually delivering more? Are we getting more throughput? Are we uh do our cycle times decrease? Do we understand, are we improving our flow efficiency across the system? So uh by doing and measuring those pieces, we can start to educate the organization and understanding uh the the flow of work in the system without um the desire to get down to the detailed understanding of every individual component and this belief that we can um have this this kind of concrete um static uh vision of what the world looks like.

Yeah, I I I find that these these changes take time because people have to understand that there's that shift in in mindset that we've just been describing. And so uh a lot of the conversations end up being um trying to change how people think of solving problems. That's one of the challenges that that uh I've often seen requires discussion and conversation and and understanding. And in particular, I'm thinking there's there's still so much um uh so much negative perspective around things like redundancy in a system, having slack in a system where people maybe aren't utilized 110% in and and so that understand like just that simple thing is driven by how budgets are taken care of, who's full-time employees, uh you know, where they're reporting to and what their responsibilities are. I think in many organizations there needs to be more of a an understanding of the value of Slack in a system and the value of people sitting around, maybe not fully utilized, doing their most valuable thing. And the example I always look at here is you actually do not want fire personnel to be busy all the time. You want them to be sitting around playing cards, thinking about preventative measures, working on less critical roles so that they are available when you need them to be doing the emergency services. Fire stations are there for that redundancy is important, it's actually a part of the resilience of the system. But too many times we don't see that in an organization. Redundancy is just not something that's built into the system. You don't look for Slack, you don't support it, it's not funded, it's not accepted, it's actually a sign of poor management practices in many ways.

Yeah, it's it's uh it's amazing how often that is the case and uh in all its forms, um both with people and with and with people with process and technology. You see it all the time. I mean, it's uh I can think of uh processes where the the desire to avoid having any slacking system causes uh investment in the wrong places, which results in a more complex system, which is more fragile as a consequence uh and uh takes longer to execute too. So the effort of trying to um avoid spending money ends up costing the organization far, far more than if they had just invested in the sufficient capacity in the first system in the first place. And uh I I see that kind of thing uh fairly frequently.

Yeah, and uh I I wanted to pick up on what you were talking about on the measuring side as well, because one of the things that we're spending more and more time talking to leaders about is uh expanding and deepening their information, gathering, let's call it, networks, that where they get information from in an organization. And that's a a response to complex adaptive systems. In in a complex system, you need to measure more and more different things to understand what's going on, not just to understand what's going on, but also to get precursors of potential problems in what's going on. And that's something that that as a leader's I think in many cases uh there is not enough time spent on broadening and deepening those information gatheringslash measuring networks, whatever that is that's being used.

I I would agree. So, how would we, as we look at this, sum this up? I mean, we we talked quite through quite a few different topics. Uh what would be your your top three uh points you would want the audience to take away from this?

Yeah, this it's been a broad conversation. I think the first one is stop chasing efficiency. And and I've I'm very careful when we're writing things down, documenting things, presenting things, not to talk about efficiency, but to talk about effectiveness. And effectiveness may not be the same, in fact, it rarely is the same as efficiency. So just to try and change that conversation. I think that's one of the key takeaways that I I think would be uh hugely beneficial. A second one, and I liked what you talked about about the capacity pieces, and I'm thinking here about those little things like learning how your systems, how the processes that you work with, um change when you constrain a certain part of the system, or you you know, you you have enough capacity. So believe before you know removing what you quote unquote think of as redundant or extra solution architects, see what happens if there's not enough solution architects.

Yes, that can because that can it also inform you a lot about like how is this system behaving. That's it.

Yeah, yeah. And and then uh and I think the the we jump to the solution in many cases way too quickly, and we probably want to be experimenting and and and understanding that by changing some of those parameters a little bit more um carefully.

And then I mean on the go ahead. I was gonna say on the software side, well, that's in my mind a classic example from this week was this idea that uh the where an organization business is coming up with some new requirements, and those they want those new requirements uh to get built in. But the the system's a monolith, and the the question was, well, can we throw more can't we just throw more people at it? Well, no, because there's a single code base, there's only one place that people can put their fingers into. The throwing more people at it won't make it go any faster. You it's uh it doesn't work like that. We've uh so it's gonna be about prioritizing the work and understanding what are we actually doing.

If you've got a galley kitchen, it doesn't matter how many chefs you've got, you've got a gap.

Or there's just no more you can do. So so there are there are other things that we can do, but um throwing more people at it isn't gonna help.

Yeah, anyway, you're you've been saying all I was gonna add is is the third one that you mentioned, which is measuring stuff, measuring what's going on. And and I think you know, this is almost a theme in every so many of our conversations. Data is so critical, understanding what's going on and measuring things. And I talked about it in the perspective of broadening and deepening information networks, but but it's the same as you know looking at what we can measure, what we can learn from it, and recognizing one number isn't going to measure my system, it's gonna have many, many different metrics and and signals that we should be keeping. Definitely.

I think the only one that I would add to that as we wrap up here is uh not thinking of the the system as a factory when it when you're dealing with knowledge work. Unless you are actually working in a factory, then don't treat it like a factory. If you are working in a factory, treat it like a factory. But otherwise, uh it's not a great analogy for for how work moves through complex systems. And so um I will leave us with that, I think. So so thank you very much again, uh Dave. It's uh always a pleasure having these conversations. Uh if anybody would like to reach out to us, they can do it. Feedback at definitely maybeagile.com. And uh uh pleasure as always. Thank you.

Excellent, Pete. Again, thanks again. Until next time.

Until next time. 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.