Business agility fails without feedback loops

 In the last 5 episodes of the Definitely, Maybe Agile podcast, we presented 5 ways Business Agility can impact your bottom line. In today's episode, we start our 5-episode series of exploring antipatterns that prevent us from achieving these benefits.

The first antipattern we're going to explore is one from our discussion in episode 44 on How business agility increases revenue. While business agility can reduce the cost of delivery, you may not realize those benefits if you forget to look at the entire system and begin to build feedback loops that allow you to learn as you progress.´

This week takeaways: 

• Watch for the signal-to-noise ratio
• Consider the influence of how long your feedback loops are on the system
• Make your system visible and understand how you'll measure 

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:05

Welcome to Definitely Maybe Agile, the podcast with Peter Maddison and Dave Sharrock to 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 Sherrock. How are you today, Dave? Excellent.

Dave 0:21

How are you doing? It's been a great uh kind of start to the year. So I'm sure we've got plenty of topics to keep talking about.

Peter 0:27

Oh, yeah.

Dave 0:28

Where do you want to start today?

Peter 0:30

Well, I thought that we could carry on our theme of business agility impacting the bottom line. Because over the last five uh weeks, we've talked about five of the key things that uh where business agility helps impact you at the bottom line. I thought it would be good to now start to delve into what are some of the anti-patterns we see, some of the things that stop us achieving those benefits uh that get in the way.

Dave 0:55

This this is one of my one of my favorite topics I've got to say is that that agile promises so much, DevOps promises so much. The benefits are very real. It's that 10x objective. The reality in many cases is organizations just don't see those benefits being realized and understandably lose faith in what they're trying to do.

Peter 1:14

And and I think there's a lot of reasons for that. And it's uh I'm quite looking forward to diving into this too. And uh and the one that we've picked for today, the one to go first, is an anti-pattern that we see around uh when we were talking about the topic of how business agility can increase revenue by allowing you to get higher quality product into market faster. And one of the anti-patterns that we see in that space is this forgetting to look at the entire system and forgetting to build the feedback loops that allow you to learn uh as you go along in the process.

Dave 1:50

It's it's an interesting one here because I think there's a really good understanding about you know what kind of agile product delivery looks like, that thing that we're aiming for, which is quicker to market, higher quality market to market, something that meets customers' needs and expectations. The reality is, of course, we need to not just get things out to market, but they have to be picked up and hit the bottom line. And as you say, if you change in one area, but you don't really look at the impact that that has across the business, you can really drop the ball on being able to see the benefits that you're hoping for.

Peter 2:26

Entirely. And it's and it's not a static thing either. We we need to continually be learning. We need to so that's why it's so important to build those out. And well, we talk about feedback loops a lot and we use this term feedback loops, but it's I I sometimes wonder if it's just not clear to people what we mean by that when we talk about it.

Dave 2:47

I think an important thing about feedback loops is there are short feedback loops and long feedback loops, right? I and and I I mean, you know, at the beginning of a year, a lot of people start looking at the feedback loop that they want to change, which is how much I'm eating versus how much I weigh. And one of the big problems that we have with that is, you know, as we start changing what we're eating and start to eat healthier and you know, reduce our calorie intake, the feedback loop, which is standing on the scale and seeing the results of that, unfortunately, if that feedback loop is too long, we don't keep the practices up that are going to give us what we're looking for. And so that brings up two critical things. One is the change might be quite variable and so very hard to pick out amongst the noise. And if anybody's got on the bathroom scales, they know that you know you've got to measure it at the same time in the same situation, because otherwise you're giving up and down. It can be quite difficult, right, to figure out what the trend is, but also the time that comes in. So there's the signal-to-noise ratio on feedback loops that we need to worry about, and there's the length of time before you actually get a response. And you know, we talk about agile teams and how if they're doing a two-week sprint, that feedback loop is really short, but that's one feedback loop. If the team takes on a feature, completes it within a sprint, great. But now we have to get that feature out into the wild, it has to have an impact on customer behavior, and that length of time before we start seeing real returns can start stretching and stretching.

Peter 4:16

Oh, totally. And uh, I mean, this is where, of course, uh my background in DevOps implementations uh comes in, where I have been in organizations where they've at least claimed that they're adopting some very good agile practices, and there's some very good practices starting to materialize in the teams. Uh, but what it's resulting is is a desire that we're now going to release more frequently. Um and I've seen this in multiple organizations where you've got teams who are saying, okay, we're going to release every month now, uh, but they haven't actually looked at what the cost of their release is, and they haven't looked at what it actually takes for them to get something out the door. And if it costs them $100,000, that was fine when they were doing it once a year. And that's $100,000 is like staff time and resources, system resources, and all of the pieces they need to make this happen. Uh now they're doing it on a monthly basis, which means it's now costing them like $1.2 million, but they're not able, because they don't have the feedback loops, they can't necessarily see this happening and the impact that it's having on the organization. And that can start to put a bad taste in people's mouths because they're like, well, how come they're paying all this money, but we're not seeing the benefits or the things we were expecting to see? In fact, they quite often end up seeing quality go down as a consequence of this.

Dave 5:32

Well, it's it's a really great point that because if you if you just as an example with that you're using there with release frequency, if you increase that frequency, there is a direct impact on cost. So the more times you release, if you don't change anything on the release cost, that release cost is going to grow with the frequency of your releases. But I find also it it's also that cost mindset that we often look at development teams, if you like. There's a lot of conversations out there about agile actually being more expensive rather than less expensive. And that's driven because, you know, to get a particular feature out, it feels like it's more expensive. But this it's also missing the whole point, which is that if we if I'm measuring how much work gets done, the cost per, let's say, work item goes up. But the whole point of this sort of customer engagement piece is that it's not how much work gets done that speeds up, it's the work that we don't bother doing because it's not valuable. So the actual, you know, the the value of the cost of work might go up, but the value that's delivered, the the return that you're getting should definitely go up much, much more because you're making decisions that reduce the wastage in the system. But if we're only counting the cost and we're not seeing the impact of reducing the waste, the you know, the things that we shouldn't be building, it's it's not going to come together well.

Peter 6:57

Yeah. And if you and you're not going to be able to tell that if you don't have the feedback loops, so because you're not gonna be able to tell what it is, the impact of the thing that you did was, if you can't actually measure and understand what that looks like, if you can't monitor for the the change and start to understand how was that received and what and as you were describing quite accurately earlier, it's like sometimes that can be a long time between the the the change that you make and uh seeing the impact um that it had.

Dave 7:27

So so it sounds to me like we've got two or three things around those feedback loops that we're looking for. What what would you say is the most important aspect, and then maybe I'll add a piece on there as well. But what's the most important piece around feedback loops that you encourage people to set up?

Peter 7:43

So for me, I mean I it's always always about make everything in the system visible. Um don't assume that you're implementing it in this one place and it begins and ends within that. And this ties entirely into our business agility conversation. Like you've got to make the entire system visible and understand how you're going to measure it. Because without without that, yeah, I like it.

Dave 8:06

It's it's it's the externality is that you the the unintended consequences of the change. And the problem with unintended consequences is you don't know where they're going to be. Therefore, you can't look for them. You have to you have to be able to look at the whole, the big picture, make it visible so that you can begin seeing some of those unintended consequences. I think that's a great place to start for sure. What would you add? Um, I I think the two things that we touched on right at the beginning, the the signal-to-noise ratio piece is uh, I don't think considered quite as much as it could be. And just the the example being how do you get you know bottom line results? The reality is the bottom line results will depend on many, many variables. And you know, rapid delivery, frequent delivery to the customer will definitely have an impact, but teasing that out from all the many other things, the marketing spend, the way the the business opportunities are changing or customers' expectations are changing, all of those different things will feed in. So there's a signal-to-noise ratio that we have to have some appreciation for or understanding rather than sort of pulling the ripcord because we think something's not happening, is understanding there is that signal to noise piece that we need to watch for. And that ties very closely to the to the wait time, the length of time within which that feedback loop will come in. I I'm I worry about saying be patient because there are very short feedback loops that you can set up and see for sure. However, there are also ones where sometimes you just need to let things ride out. And I think that the understanding between those, being able to articulate this is a long feedback loop, this is a short feedback loop, we expect to see change quickly here. We're not going to be able to influence change rapidly here, is important to understand.

Peter 9:52

And and making that very, very clear and visible to the people who care about this in the organization, so that they're not uh so that they're expecting that and they're not getting something that uh they weren't expecting, or they're not seeing the change that they're expecting to see. So there's got to be understanding around that. So I think that's good. I think uh I I always enjoy these uh conversations. I hope this was valuable to people and uh and we can wrap it up there for today. And uh as always, you can get back to us at uh feedback at definitymabyagile.com. And uh I'd like to thank you for the conversation as always, Dave. As always, a pleasure, Peter. Look forward to the next one. 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.