Business agility fails when speed is confused with focus

 Now we are going to talk about our second antipattern that came up in episode 43, being unable to say "no". This often presents itself as confusing speed with focus.
This week takeaways:

• Reducing delivery costs starts with saying no.
• Prioritize and concentrate efforts in one place.
• Limit work in progress
• Automation is essential.

  We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com 

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David 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 Maddison and David Sharrick. So how are you today, dave?

David: 0:21

Very well. It's been a great start to the year, so I'm enjoying kind of looking ahead and seeing what 2022 brings to it.

Peter: 0:28

Okay. Well, it's been exciting so far and it's certainly very, very busy. So I mean, what are we going to be talking about today?

David: 0:36

Well, since you talked about being busy, I think, just touching on some of the, we've talked a little bit before about reducing the cost of delivery, about focusing on the right things, and I think periods when we are exceptionally busy are times when we sometimes forget the discipline of focusing on the right thing, of saying no and really kind of getting things out of the door as a priority, rather than being busy and keeping lots of plates in the end.

Peter: 1:05

Yeah, and this is a common problem, because we often find ourselves, especially this time, when we start off with this really great focus. We know exactly what we want to get done and as time goes on, lots of things come in and interrupt us and more work starts to pile up and we slowly lose that focus. Things start to drift and and it becomes harder and we have to remember it takes work and effort to pull ourselves back to make sure we are continuing to focus on achieving the outcomes.

David: 1:34

Well, it's interesting you mention that because, yeah, new Year's resolutions, we all have great plans. As we come into a new year, it's a very common time for us to kind of assess what we're up to, but it's the executing against those which is difficult, because it's, I mean, there's a couple of things that come into that. One is you know, what starts as really a clear objective gets muddied as we add more and more layers of well, if I'm going to do this, then maybe I could do this as well. I could do this as well. So if I think of, you know, my goal is to get fit, then maybe, as well as my goal is getting fit, maybe I'll add to that diet and how I'm going to change how I eat. Or you know, the dry January thing that comes through this, and as you add more and more moving parts, then the attention on any one part of that gets less and less as well, gets more difficult. Let's maybe bring this back to a technical delivery context, right?

Peter: 2:28

Let's focus on that I was about to say yes. When we think about this in terms of business agility to bring it back to business agility what we often see when business agility fails. When people try to adopt more business agility, bring in these practices into their organizations, one of the problems that they encounter is they end up confusing speed with focus. They end up trying to do too much and trying to go faster and faster and faster, and then, going faster, take on more work than they can handle, and that causes them to lose focus and you end up with too much outstanding work, too much work in progress, and work in progress is the ultimate enemy of flow. It's the ultimate enemy of us actually achieving the business agility that we're looking to achieve.

David: 3:14

Well, it's interesting because I think we get confused with the word speed. We all know what speed is in kind of the world around us is in kind of the world around us, and so when agile or DevOps or any of these new ways of working promise increased speed, our view is that we're going to be able to move faster and go from 10 miles an hour to 20 miles an hour, or 10 kilometers an hour to 20 kilometers an hour, metric or non-metric right, but speed isn't.

David: 3:39

That's not what's really about. The speed that we're talking about is doing the work probably at the same pace that the teams have always done, or even a little bit slower, because they're now going to focus more on quality. I'm going to talk later on about automation and technology. They're going to introduce actually more workload for the work that's in the pipeline. So the key to speed is not kind of working faster or harder, but working on the right things and doing less of the wrong. And this is that classic. If you look at value stream mapping, the value stream map, when we look at value-added activities versus non-value-added activities, the way we get an improvement, a shortening of the amount of time it takes to get something out of the door, is not by doing the value-added activities quicker, but by eliminating the non-value-add activities much, much easier.

Peter: 4:34

Yeah, I use this in my own work and I use Eisenhower's matrix. You know what's urgent and important versus not urgent and not important and the not urgent not important. Yeah, we don't worry about that, we're just going to forget about it so that things are prioritized on what do I have to get done now, because it really is truly urgent and important, and what's not urgent and important is the stuff I really should be working on, and that's the stuff that comes next, and then everything else can be forgotten about.

David: 5:05

Well, I mean, I always think of agile speed. That is less wrong, things not faster, right things Right is less wrong. Things not faster, right things right. So we really need to help management leaders get away from the idea that we're going to deliver things faster, except in one really interesting place, which is automation, because I think that's all of a sudden where you get that exponential changes. If you're, for example, able to get something out of the door not in eight days for a release cycle, you know it takes maybe eight days in some organizations or longer, to get something through all the hoops to get it out of the door. Well, what can we do from a technology perspective to get that X number of days down to X number of hours or minutes? Now we're talking a lot more about that kind of speed of delivery, but the interesting thing there is it's not about the work that's being done, it's about how to get it out of the door typically. Would you agree? Is there other areas that you'd look for automation to contribute?

Peter: 6:02

I think that I mean the automation is critical. Understanding that anything that you have that is not currently in front of the customer and creating value is currently work in progress. It adds no value. It's just sitting there on the shelf, and so we need to make sure that we get that to the customer as quickly as possible for so many reasons. Last week we were talking about feedback loops and we need to be able to, as quickly as possible, learn is this the thing that the person we're delivering to wants? Are we creating the right capabilities, the right functionalities, the right things that the customer needs to see, and making sure that that happens as quickly as possible? This also benefits us in other ways on the risk side, so that when things go wrong, we're also able to respond faster and fix things faster and deliver more value. We can also look at this, too, in that we have no risk until it's live, so let's make sure we understand what the state of things is.

David: 7:03

Well, and I think you bring a really good point up there, which is, I mean, there is that whole thing is there's no value if it ain't live, but there's also no risk if it ain't live. So that brings us to another place where automation plays a really critical role If we're really going to speed up the delivery of new functionality into the wild. One of the things that we really need to use automation for is to create confidence that the things which are going into the wild aren't increasing the risk that we're taking, and that whole conversation around regulatory or compliance and those activities which are often the wait times are often a big component of the non-value add in any sort of a value stream. How do we safely automate and speed up those key touch points, those key validation steps that we need to go through in order that we're not increasing risk by sending things live more quickly?

Peter: 8:00

Exactly exactly. I think we've touched on a lot of really great points today. How would you like to sum all of this up?

David: 8:08

Yeah, I think what's really interesting I think you said it right at the outset which is understanding that reducing the cost of delivery starts with saying no or at least not now, maybe later to the many different opportunities we have in front of us.

David: 8:24

That idea of prioritizing and focusing our efforts on one place rather than somewhere else right, that's number one. The second and we kind of touched on that by talking about not confusing speed with focus and we want that focus in where we're at. The second thing that comes out is that whole idea of sort of limiting work in progress, and this is fundamental. We've talked about this many times and when you've worked with systems and you've seen this happen over and over again, it's almost a given to the point that it's in a DNA of any solution that we're putting forward. But I think it's important to pull this one out and give it a decent flag and a wave again, which is that idea of reducing the number of items we work on. Get those out of the door and then pick up the next thing, not just focus on more and more activities, not just focus on more and more activities.

Peter: 9:16

Yeah, and I think that understanding of what is the most critical, important thing, that prioritization is part where the organization needs to help with that, because quite often you can see that when you start to look at the end-to-end flow you mentioned value streams earlier when we start to look at the end-to-end flow, we realize that problems are actually happening on the far left because we're just generating too many things to work on and you've got limited capacity to actually work on those and even more limited capacity to actually deliver them in a manner that we can consume the learning.

David: 9:51

so we need to make sure that we understand all of the stages that we need to go through in order to be able to create value and not just look at the pieces individually to make sure we understand where is our work in progress, One of our your favorite topic, but our favorite topic which is around that whole technology and automation, and I think we all know that automation, DevOps, that sort of investment in the infrastructure and the environment and how to get things through the process and the practices that we've talked many times about. It requires investment, but I think when it's done in the right way, the return on that investment is huge and it's an exponential lever that we're able to apply to this to get things out of the door quickly Shortening feedback loops, increasing confidence around risk mitigation and just getting things like out of the door with fewer and fewer of that time spent on non-value-add activities. I think it's essential.

Peter: 11:00

I think it's a very good way of putting it, and with that, I think we should wrap up for today and I'd like to thank all our listeners. Always, you can send us some feedback at feedback at definitelymaybeagilecom, and we look forward to having you listen to us next time.

David: 11:15

Excellent, always a pleasure. Look forward to the next time.

Peter: 11:17

You to having you listen to us next time. Excellent, always a pleasure. Look forward to the next time You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharock, focus on the art and science of digital agile and DevOps at scale.