How do you know you are going in the right direction?

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 Maddison and Dave Sharrock. How are you doing today, Dave?

Very good, Peter. It's always a pleasure to be here because that's uh yes, you definitely raise the roof on the uh the kickoff of our conversation here.

It's always so fun because you're gonna be energized and I'm gonna go into it. Bring the energy.

So which is a great uh segue into what we're talking about. So um when you say bring the energy and energize, how uh how do you know that the energy that you're bringing, the energy, the energizing that you are doing is going, moving things in the right direction?

It's it's a very good question. I mean, uh, any time, and we have been talking about digital transformation through this uh second season of our podcast, and over the last few episodes, we've explored this in a number of different ways. And uh one of the key pieces, I think, here is understanding how are you gonna actually measure your your progress as you go. And we know that we have uh leading metrics and our lagging metrics, and leading metrics are, I think, the ones which are gonna most help you tell you whether you're going in the right direction. We're looking for what are changes that are happening that are indicative of the behavior change you're looking to create. And when we talk about digital transformation, we're talking about the way that the organization is is transforming. Uh, we want to look for things which are what are the behaviors we're looking to change as we make go through the transformation, and how might we find metrics which show us that uh those behavior changes are actually happening.

Well, I think I think there's a couple of benefits from that, right? One is just knowing you're on track. Like any sort of change, you want to make sure A, you're not stuck in the mud, you're not stationary, but you're moving forward in some way. And if you are moving, you want to make sure you're moving forward, not backwards or sideways or whatever it might be. Uh I think I would say one of the underrated reasons of wanting to know you're going in the right direction is the motivational aspect. That keeping people on track, keeping people on board, rewarding the change that feels like small, kind of hard-fought wins in the early stages and being able to really build the energy, the momentum, hence the energy and energizing comment at the beginning, right? Being able to build a little bit of buy-in and support and motivation into the changes going on as well. Maybe to kick things off, though, let's start like the the step one surely is understand the problem that you're solving for, right? Well, how does that feed into it? Would you say that's the first thing we worry about?

Uh it it is. I mean, we there's got to be something uh that's going to be uh understanding the problem is uh what is how's that uh phrase go again? If you a problem understood is a problem half solved, something along those lines?

It's the or a problem shared is a whatever it is. Yeah. Right. That's particular about what you're doing.

Yes. But the so that understanding the problem that you're looking to solve with the the change that you're looking to undergo is is critical. And so you can almost not spend enough time on it, and people very rarely do, because you get to the point where we've got to get started, we've got to start learning, we've got to start um experimenting to learn. Um, but we do we do really need to understand what is the problem we're solving for, to have an understanding of what we're gonna be doing.

I I think it's very easy as well to forget that the view you have of the problem that needs solving when it's in front of you and so patently obvious what the change has to be is not necessarily the view that the rest of the organization might have, who don't have the benefit of standing where you are standing, of having the experiences that you may have been experiencing. So, what is the problem you're solving sounds trivial, but actually turns down, you know, if you look at Cotter's eight steps for transformational change when he talks about a sense of urgency and it talks about communicating what the objectives are, that communication is over and over again. Communicating is helping people understand what that problem is and getting that in front of people so they they recognize it and and there's some sort of change against it. I think there's another element, which is is we have to have a problem that is understandable, articulated well, and understandable from the perspective of the various parts of the organization that we are trying to motivate to change.

Yes, yeah, that that and and this is a common problem when uh a good example of this is something like uh cloud computing or something that's highly technical in nature, and uh we come along and say this problem solves all of the different things that we need to do, and the person on the other side of the table is going, This makes no sense to me because you're explaining about speeds and feeds and pipes and tunnels, and you're you're talking about a whole bunch of things which mean nothing to me. So, how how am I supposed to relate this to my world and the language that I speak and the problems that I see?

I I really like that example because it highlights a couple of things. One of them is the danger of poorly articulated problems, like we need to be in the cloud. Does that mean a hundred percent of the servers that you have in your organization are trashed and replaced because we've moved that all of that into the cloud? Does it mean some of it, all of it, what services? So there's a level of detail that we have to help people understand to make trade-off decisions, to understand whether or not the services that they're using are going to be transitioned sooner rather than later, and all of these things. So there's an articulation element of just be specific about what you're trying to change. And the the bit that I'm always looking for is the absolute that all of our uh servers need to be transitioned into the cloud, or all of our services need to be transitioned versus these ones versus these ones versus these ones. So you're looking out for those absolutes and being very careful because the absolute is actually instead of being this big motivational push, is actually the opposite because we just roll our eyes and say, Yeah, that doesn't mean anything. That's one part of that articulation. The second thing I really like about that cloud example is um the impact is it's a solution, not the change itself. And so if I'm a user of those services, I need something that helps me understand why I should care about it rather than just knowing some sort of infrastructural change is happening. What does that mean for me? Do I get better service, better response times, whatever it is, what am I going to see that is different?

Right. It's the uh how does how does this matter to me? What's in it for me? The the Wiffin Kund, right? I I've got to understand this from my perspective in a language that I understand in order for me to buy into this being something that needs to happen, for me to prioritize it versus all of the other things I could possibly be doing. And uh, and if you're if you can't say this is gonna impact you in all these different ways, then uh you there's got to be a reason behind that that I can understand for me to buy into it. The uh the other piece that we were talking about um was around um baselines. So that this is a common mistake. I've seen this in many organizations. I remember one I was I came in after they were part way through a number of activities in like a DevOps style transformation. And uh one of the uh the problems that they had um not long after I got there was that uh they were asked, well, how much progress have we made? And very rapidly it became apparent that, well, they'd never actually measured where they started from. So it was in pretty much impossible to see how much progress they'd made because all they could really tell was that something had changed, because we've done things, but we can't really tell you what it was that happened as a consequence of what we did and uh or what the impact we had.

And I I you know that's something that we see so many times, of course, is there isn't a baseline from where to measure things against, but we also want to combine that with a prediction of where we expect to get to, so that that prediction can say, you know, even if I have upward movement in whatever metric I am trying to measure for upward movement, there's a big difference between upward movement of a tiny little bit that's maybe within the noise or to be expected, versus upward movement that was the objective of spending the time and energy and finances and so on that we have done in order to make that change. And I think that's an important piece because we want to we want to that's how we learn. If we don't have that predictive element, then we're gonna claim any forward motion potentially, any forward motion is a success, rather than taking the opportunity to look at what we could learn, what we can do differently, what maybe uh are challenges that still need to be resolved.

Now, turning all of this on its head, of course, we've we've just talked about a whole ton of things. So you've got to baseline it, we've got to define the problem up front, we've got to make sure that this is all well articulated. That sounds like an awful lot of work before we even get started. So, what else do we need to consider here?

It's it's it's a catch 22, isn't it? So here let me let me just pick up on like the other side of that as well. And then we'll we're obviously gonna have to touch on leading and lagging indicators. But before we do that is on the other side of it is, and I always think of driving through tunnels in the mountains. You you know that thing that you do with your kids where you get them to hold their breath as you drive through a tunnel, you're trying to get to hold the breath until you get to the end of the tunnel. And as the parent driving, you're slowing the car down, but you can have some fun with it. Anyway, what do you do to torture your kids? But the the reason I mention that is the holding your breath in any organizational transformation is the gap between we are beginning to change and the first visible step is delivered. And there is there is so much benefit in having lots of small steps that happen one after the other, like stepping stones across a stream versus holding your breath and saying, when this change lands, when we get this big thing that we're working towards, our whole life will be fantastic. We'll have flying cars and this and that, and the other will happen. And those small, measurable steps, incremental delivery is so critical. I mean, it's baked into the Agile Manifesto. Um, it's baked into so many of the practices that we see in, say, DevOps and so on. We sometimes forget to build that small measurable delivery plan and follow that through for making sure we're going in the right direction or making sure we're A, going in a direction, but then it's the right one and we're getting the change that we want.

Exactly, exactly. It's uh I guess I find it's uh when we start to talking this language, sometimes it it makes it sound like we're we're ignoring the fact that we'll we we've we do also need to get stuck, we need to look at and how do we experiment to learn whether we're going in the right direction as well, especially if it's something we haven't worked with. So there's the there's these different elements of it, understanding the problem space that we're operating within, so that we know where we're going and we've got an outcome that we're looking for that we we can articulate and we can understand, and then running uh and creating small measurable steps we can start to incrementally move forward and learn as we go so that we can see um what are we doing and where are we going. And this is of course where our leading and lagging metrics come in to help guide us on the uh journey.

Well, I know I think that's it, is I like if you don't have those deliverables, you can't measure much of anything. So you need the deliverables to get a data point that makes sense, so that we can look at it. And then so leading, lagging indicators. I always think that one is somewhat obvious, but lagging indicators are typically the ones that you're aiming for. That's your sales growth, your profitability, your you know, fewer FTEs needed to bring this, that, and the other to the market, or whatever it might be. These are lagging indicators, they happen effectively. You can measure it once you are successful. And the leading indicators are much harder to define, but the leading indicators are the ones that lead you towards it. They tell you that you are moving and they tell you that you are moving in the right direction.

I I like to describe it as the leading indicators are the indicators of the behavior change that you're looking for. So if you understand the behavior change you're expecting to see as a part of the step that you're taking, then you look for the leading of the leading indicators are the ones that are going to start to indicate that that behavior change is starting to occur. And this gives you an idea of am I going in the right direction? Are the actions I'm taking, the the experiment, the hypothesis that I have getting me towards the uh the outcome that I need.

Absolutely. So as you're describing that, I mean, just imagining if if you're trying to get fit, then your leading indicator is are you taking time to go work out, go for gym to the gym, run, whatever it is? And if you are taking that time, are you taking more time than you were before? So these are often I really like the way you describe it. These are often behavior changes, user behavior changes that cumulatively will result in the change that you're looking for, but that are really just like those little observations that yes, something is changing here.

Uh so how are we gonna sum all of this up in three points for our listeners?

Um, I I if I just summarize, I mean, I I I think the incremental delivery is huge. So there's somewhat that we started off with talking about are we solving a problem that we understand well that has been articulated baselined and so on. I think that's somewhat obvious. So the bit that really stands out to me is incremental delivery. Like I'll take that one to the bank over and over again. Uh the other two things that what the what problem are you solving? I think it's a lot harder than people sometimes think, and it does require that little bit of you know, pause, reflect, think about things before we dive into something.

And then I think it's also important to go back and check in and verify. Close that loop, close that loop.

Yeah, absolutely. Yes, and I think that can be something that we forget about. I mean, at least the the incremental delivery often sort of replaces that at some point because we're seeing that change perhaps. Um, yeah, and then we talked about leading and lagging indicators, and I think we could spend a lot more time on that. That one is uh I I've very rarely seen that really dissected appropriately and kind of put together. I think finding leading indicators is hard, they're often proxies. Lagging indicators, honestly, by the time they change, it's often too late. So there's a lot more to dig into there, but I think the the concept is is pretty clear. It's just that we might want to discuss that in more detail at some future show.

Sure. Sounds uh sounds good to me. I look forward to it. So so with that, uh, if anyone wants to send us any feedback, they can at feedback at definitymabyagile.com. And uh I look forward to the next time. Next time. Thanks again. 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.