Ep. 79: Are going in the right direction?

[00:00:00] Peter Maddison: Hello, and welcome to another exciting episode of definitely Maybe Agile with your hosts, Peter Madison and David Sharrock. How you do today, Dave?

[00:00:07] Dave Sharrock: Very good, Peter. It's always a pleasure to be here because you definitely raise the roof on the kickoff of our conversation here.

[00:00:13] Peter Maddison: It's always so fun. Be energized and I go into it, right? Bring the energy!

[00:00:18] Dave Sharrock: When you say, bring the energy and energize, how do you know that the energy that you are bringing, is moving things in the right direction?

[00:00:25] Peter Maddison: It's a very good question. We have been talking about digital transformation through this second season of our podcast. Over the last few episodes we've explored this in a number of different ways. One of the key pieces here is, understanding how are you going to actually measure your progress. We know that we have leading metrics and lagging metrics. Leading metrics, the ones which are going to most help you tell whether you're going in the right direction. When we talk about digital transformation, what are the behaviors we're looking to change as we go through the transformation? And how might we find metrics which show us that those behavior changes are actually happening.

[00:00:59] Dave Sharrock: I think there's a couple of benefits from that, right? One is just knowing you're on track. Any sort of change, you want to make sure 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. I would say one of the underrated reasons of wanting to know you're going in the right direction is the motivational aspect. Keeping people on track, keeping people on board. Rewarding the change that feels like small, hard fought wins in the early stages. Being able to really build the energy, the momentum, buy-in and support and motivation into the changes going on. Step one surely is understand the problem that you're solving for, right? How does that feed into it? Would you say that's the first thing we worry about?

[00:01:41] Peter Maddison: Understanding the problem that you're looking to solve with the change that you're looking to undergo, is critical. You can almost not spend enough time on it. We do really need to understand what is the problem we're solving for, to have an understanding of what we're going to be doing.

[00:01:55] Dave Sharrock: It's very easy as well to forget that the view you have, 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. They don't have the benefit of standing where you are standing. Of having the experiences that you may have been experiencing. What is the problem you're solving, sounds trivial. Over and over again communicating, is helping people understand what that problem is and getting that in front of people so they recognize it. There's another element, which is we have to have a problem that is articulated well and understandable from the perspective of the various parts of the organization, that we are trying to motivate to change.

[00:02:39] Peter Maddison: Yeah. This is a common problem. A good example of this is something like, cloud computing. 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 speeds, and feeds, and pipes, and tunnels. You're talking about a whole bunch of things, which mean nothing to me. How am I supposed to relate this to my world, and the language that I speak, and the problems that I see?

[00:03:01] Dave Sharrock: 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 services that you have in your organization are trashed and replaced because we've moved all of that into the cloud? Does it mean some of it? All of it? What services? There's a level of detail that we have to help people understand to make trade-off decisions. Whether or not the services that they're using are going to be transitioned sooner rather than later. Be specific about what you're trying to change. I'm always looking for absolutes. That all of our servers need to be transitioned into the cloud. You are looking out for those absolute and being very careful because, instead of being this big motivational push, is actually the opposite, because we just roll our eyes and say, "that doesn't anything". The second thing I really like about that cloud example is it's a solution, not to change itself. 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 changes happening. What does that mean for me? Do I get better service, better response times? What am I going to see that is different?

[00:04:14] Peter Maddison: How does this matter to me? What's in it for me? I've got to understand this from my perspective, in a language that I understand, in order for me to buy-in to this being something that needs to happen. The other piece that we were talking about, was around baselines. This is a common mistake. I've seen this in many organizations. I remember I came in after a DevOps style transformation. One of the problems that they had, they were asked how much progress have we made. Very rapidly it became apparent that they'd never actually measured where they started from. It was pretty much impossible to see how much progress they had made, because all they could really tell was that something had changed. But we can't really tell you what it was that happened as consequence.

[00:04:53] Dave Sharrock: That is one we see so many times of course, is there isn't a baseline from where we measure things against. We also want to combine that with a prediction of where we expect to get. Even if I have upward movement in whatever metric I am trying to measure, there's a big difference between upward movement of a tiny little bit, versus upward movement that was the objective of spending the time and energy. That's an important piece because that's how we learn. If we don't have that predictive element, then we're going to claim any forward motion as a success, rather than taking the opportunity to look at what we could learn. What we can do differently. What are challenges that still need to be resolved.

[00:05:29] Peter Maddison: Now, turning all of this on its head. We've just talked about whole ton of things. You 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. What else do we need to consider here?

[00:05:43] Dave Sharrock: It's a catch 22, isn't it? Let me just pick up on the other side of that. I always think of driving through tunnels in the mountains, you know that thing that you do with your kids, where you get them to hold their breath as you drive through a tunnel. The holding your breath, in any organizational transformation, is the gap between we are beginning to change and the first visible step delivered. There is so much benefit in having lots of small steps that happen one after the other, versus holding your breath and saying, "when this change lands, our whole life will be fantastic". And those small measurable steps- incremental delivery- is so critical. It's baked into the Agile manifesto. It's baked into so many of the practices that we see in DevOps . We sometimes forget to build that small measurable delivery plan and follow that through for making sure we're going in the right direction.

[00:06:36] Peter Maddison: Exactly. Understanding the problem space that we're operating within so that we know where we're going. We've got an outcome that we're looking for that we can articulate and we can understand. Creating small measurable steps, we can start to incrementally move forward and learn, as we go so. And this is of course, where our leading and lagging metrics come in to help guide us on the journey.

[00:06:57] Dave Sharrock: If you don't have those deliverables, you can't measure much of anything. You need the deliverables to get a data point, if that makes sense. Lagging indicators are typically the ones that you're aiming for. That's your sales growth, your profitability. Effectively you can measure it once you are successful. And the leading indicators are much harder to define. The leading indicators are the ones that lead you toward it. They tell you that you are moving. And they tell you that you are moving in the right direction.

[00:07:26] Peter Maddison: I like to describe it as the leading indicators are the indicators of the behavior change that you're looking for. If you understand the behavior change you're expecting to see, then the leading indicators of the ones are going to start to indicate that behavior change is starting to occur. This gives you an idea of, "am I going in the right direction?". Are the actions I'm taking, the experiment, the hypothesis that I have, getting me towards the outcome.

[00:07:49] Dave Sharrock: Absolutely. If you're trying to get fit, then your leading indicator is, are you taking time to go work out. And if you are taking that time, are you taking more time than you were before? These are often behavior changes. User behavior changes that cumulatively will result in the change that you're looking for.

[00:08:06] Peter Maddison: So how are we going to sum this up in three points for our listeners?

[00:08:09] Dave Sharrock: I think the incremental delivery is huge. I'll take that one to the bank over and over again. The other two things: what problem are you solving? It's a lot harder than people sometimes think, and it does require that little bit of pause, reflect, think about things before we dive into something.

[00:08:25] And then we talked about leading and lagging indicators, and I think we could spend a lot more time on that. I've very rarely seen that really dissect appropriately. 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 concept is pretty clear. It's just that we might want to discuss that in more detail.