Risk & Agile – Why Moving Fast Doesn’t Have to Break Things

Can agile teams really move fast without breaking stuff? In this episode, Dave and Peter dig into one of the biggest tensions in modern software delivery: the push for speed versus the need to manage risk.

They unpack the idea that when agile is done right, it actually helps reduce risk, not amplify it. You’ll hear stories and analogies (yep, including a messy kitchen and airplane cockpits) that bring this idea to life. Along the way, they highlight why teams that obsess over "faster delivery" often end up with systems that are, well, kind of fragile.

Whether you're navigating compliance hurdles, trying to foster psychological safety, or just figuring out how to move fast without chaos, this conversation brings a grounded, practical take on how agile and risk can work together, not against each other.

This week’s takeaways:

• Learning continuously is more powerful than just moving quickly
• Teams should feel safe to say “something doesn’t feel right”
• Focus on what’s working, not just what’s broken

Chapters

• 0:00 Introduction to Risk Management and Agile
• 2:55 How Agile Mitigates Different Risk Types
• 6:10 Building the Wrong Thing: Field of Dreams Risk
• 9:37 Risk Culture: Learning vs Delivery Focus
• 14:38 Safety Systems: Band-Aids vs System Improvement
• 18:50 Key Takeaways and Conclusion

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 Dave, how are you doing today?

Dave [0:14]: Excellent, Peter! Good to see you again.

Peter [0:17]: It's another exciting day at the farm.

Dave [0:21]: All right then. So what's happening at your farm today?

Peter [0:32]: Well, I thought we might have an enjoyable conversation about risk management.

Dave [0:35]: Only you could say this is going to be an enjoyable conversation about risk management! laughs

Peter [0:38]: Well, I like the topic. And in particular, we wanted to talk very specifically about risk and agile, because these two things are closely related. They go hand in hand. There's lots of writing in this space from some key names, so let's talk through the concepts.

Dave [0:58]: This is definitely a noteworthy topic. I like this because you're tying together one of our favorite topics—agile, which has been a conversation starter for many of our discussions—with something that's been emerging in quite a few recent episodes. Risk isn't this group over to one side that we kind of have to work with every now and again. It's something organizations really need to be talking about and creating a culture where it's transparent and openly discussed.

When I look at agile and risk coming together, I think this is a bit of a reaction to agile teams going to build more, going to get to market quicker. That chase for speed is always going to conflict with the gatekeepers around compliance, regulatory stuff, security—all the things we associate with risk. So that tension has been coming to the fore more and more. I think you and I have both experienced scenarios where the brakes are being put on teams because trust is breaking down.

Peter [2:02]: Yeah, and there are a lot of reasons why we see more of this. There are macro problems driving more risk in the environment that organizations exist within, which requires them to figure out how to incorporate that into their processes. Technologies like AI bring a lot of capability for organizations to be easily disrupted, or for disruptors to have tools that make it very easy for them to disrupt organizations. I can, for example, write an email that looks very much like one from your bank and send it to you. Lots of things that before would have been difficult to do have now become very easy.

Dave [2:52]: But I also think a lot of this has to do with later adopters. Maybe it's that dilution we've talked about, where it's agile in name only or agile with a very strong overlay of project management mindset. They think it's all about driving teams to deliver faster, deliver more quickly, when actually organizations that really understand agile get a lot of extra gears. You can definitely move in that direction, but you can also do it safely or with much more awareness of what you're doing. If you have a strong culture of continuous learning, with empirical data driving how teams develop, what they work on, how they address problems—all of those are there to manage risk, even if it wasn't explicitly discussed in the past.

Peter [3:44]: Yeah, and I realize as we're diving into this, we're very specifically talking about technical, operational risk—the risk involved in delivering a new product. Now there are other types of risk that will potentially be impacted. For example, there are risks of entering a new marketplace. Do we understand that marketplace? Do we understand what we need to do? I think agile has a very strong role to play in mitigating that type of risk too, because it's the type of risk that benefits from fast learning. Can I build a system that can learn about that environment and react and operate within that new space faster, so I can gain that market?

Dave [4:31]: I think we should clarify that when we talk about agile, we have a very broad definition. What we're talking about there rolls in product management, product-centric approaches, some of the things that... we're going to encompass as many of these as we can, right?

Peter [4:46]: Exactly. Well, agile organization—this is drawing that boundary around these things.

Dave [4:50]: So here we're talking about an agile organization that is building a product and how it can manage the aspects of risk involved in building, developing, deploying and operating that product into the marketplace. I feel like what we're calling out—naming and shaming almost—is if I become very narrow in my focus and think agile means rapid delivery, more work out in a shorter timeframe, then I'm actively creating a more risky approach. Purely from technical delivery risk, but I'm also going to be adding it from a viability and desirability risk and all the other things we look at when getting products out the door. And that's before you broaden that conversation to a lot of the other families of risk that organizations are having to deal with now, whether driven by AI, geopolitical risk—which I never thought we'd talk about as frequently as we have recently.

Peter [5:49]: Well, I mean, the risk of building the wrong thing is one of the large risks that agile helps with. It's the "field of dreams" problem where we build the baseball stadium and nobody's going to come, because we've done all the planning, all the analysis, all the design, and now we're going to build the product. We spend all this time building the product before we ever put it in front of the customer. There's a lot of risk in all that upfront work. If we don't truly understand what the customer wants, we're going to end up building the wrong thing.

Dave [6:23]: So just to define terms a bit—can you tell me about your thinking around why risk is all of a sudden a point of conversation? And then secondly, how do we go about handling this? Because we can't just say agile teams solve the problem. We've just said it's actually not that simple in many cases.

Peter [6:49]: No, and that's because there are lots of types of risks. Some things you're doing, you'll mitigate the risk better by spending enough time understanding the problem upfront and putting together a well-designed solution before taking action. Some problems are better solved by setting a short time horizon, working out what's the first small piece of value we can create and deliver that will let us learn, and then using that learning to decide what our next step is going to be. Which is agile in a nutshell, so to speak.

Dave [7:30]: What you're describing sounds like the exploration route, right? We've often talked about agile being a great way of exploring, of taking a few steps forward and then looking around and reassessing and saying "are we still happy with the direction we're going in?" It's really well suited to emergent, volatile risks that we can't really know about until we make steps in that direction. But to your point, there are other risks which we do know quite a lot about and we can actually deal with without having to do that exploring approach.

Peter [8:06]: Yeah, I want to pull on a thread there a little bit too. The volatility—you might be operating in an environment where your system is complicated but known, where the delivery works and what you need to do is clear. But volatility of the external environment you're operating in causes you to have to switch into a more exploratory nature. And organizations, especially if they've been running that system for a very long time, tend to be very bad at doing that. They have inertia in their structures and processes and how they work. The culture they've built up, the identity of all the individuals in the system are tied into how the system operates, and now you've got to go and change it.

Dave [8:53]: As we're playing with that topic, it actually brings out one of the critical things we're looking for, which is a culture that's ready to call out risk, a culture that's always ready for change.

Peter [9:04]: You need a culture that's... it's not that you need to be preparing for "maybe I'll need to do this." You need one that's already doing it.

Dave [9:23]: Yeah, that's the habit. They need the muscle. They need a habit of continuously re-evaluating and changing and improving, or at least taking different steps forward, so they're continually exploring their space. That's for sure.

But I'm thinking even more than that. The analogy I'm thinking of is we just had a recent conversation around cybersecurity where we were talking about how, if you start using software that you use every single day—your browser, whatever it might be—and it's behaving in a subtly different way, there are cultures where we just kind of roll our eyes, look to the sky and then carry on. Reboot, turn it on and off again and keep going, hoping it's going to go away. And then there are cultures that start raising tickets to say something's wrong. I think it's that second one—being in a culture where we welcome observations that don't necessarily have a root cause we can immediately point to. A safety culture where we can say "this doesn't feel like the right thing to do" or "this doesn't feel like it's working correctly," and that isn't just shut down because we're busy and need to get to the next thing.

Peter [10:26]: Yeah, and that culture which is willing to question "is this the right thing to do in this circumstance?" and understanding what that means, and willing to put their hand up and say, "hey, I'm not sure we should be doing it this way. Could you help me figure this out?" Which brings us to something we were talking about before we started recording—the piece around how in some agile teams, it gets very focused on delivery, and the purpose of agile is built to deliver things faster, versus the concept of agile being for continual learning and continuous improvement. That part being absolutely critical. If you don't have that, then you're actually going to start to incorporate more risk into the system. It's that missing element of looking at something within every iteration that you're incorporating and asking "what did we just learn? What did we learn from this?"

Dave [11:25]: It's fascinating because what you're describing there is that concept of a learning organization. You know, it goes back to learning cultures from the early 90s... laughs It's scary when we keep going back and looking at how far back these conversations have been going. But an agile team helps you deliver more quickly by learning and continuously modifying how it delivers things. Well, if I lose that second half of the sentence, I get caught up with "agile's about delivering quick" and not the learning. And now I'm building a more brittle system.

Peter [11:58]: I think that even the very last piece you said there gets lost on people. People don't realize that by not incorporating the learning back into the system, by not looking at what you do, by not solving for the impediments you see in front of you and continually improving how you deliver, you create a more brittle system and that is going to lead you into trouble over time. At some point... there are lots of analogies for this. The dirty kitchen is one—you've got to keep your kitchen clean, otherwise eventually you'll run out of dishes and you won't be able to make dinner.

Dave [12:36]: Or you discover penicillin as you go through, I assume. laughs

Peter [12:39]: Yeah, well, actually there's a whole other level to the analogy. You discovered something good in the mess, but potentially now we need to pivot the entire organization to making drugs rather than food.

Dave [12:53]: So I think we're moving into the idea of slack in the system. You've got space for these exception opportunities to emerge, and so on.

But yeah, I mean, I think if I look at the takeaway, without getting into the food analogy too far, the takeaway of our last few minutes of conversation is this—the continuous learning is a massively critical element. Not just continually pausing and learning, but applying it, trying things out, using that to explore and modify how you do things. And that's based on a culture where we can say, "hey, I'm not happy with what I'm seeing right now, something feels off" and that not being shouted down or pushed to one side or ignored, but it's actually a contribution to a discussion that's a regular discussion.

Peter [13:36]: Yeah, and I think there's another piece. One of my favorite people in this space, Dr. Sidney Dekker, talks a lot about safety environments and what works and what doesn't. He often talks about it in terms of organizations operating in a Safety-I culture where they focus on what fails and put mitigations in for the things that fail. But that's basically trying to play whack-a-mole with what you see coming at you. There is a baseline of things we know we should be looking for, but beyond that, if we only ever put band-aids over the stuff that fails, we'll not only end up potentially identifying one-off pieces and putting a lot of time and effort into band-aids...

What we want to do is focus on Safety-II, which is what's working well? What are the right actions that happen more often? Let's ensure the right thing happens more often versus focusing on the wrong thing. So this is a good way of thinking of safety systems. What are we focusing on here? Are we trying to ensure that we're building the system in a good way and strengthening the right actions and making sure those occur? Or are we spending all of our time and effort on all the things that could possibly go wrong and just putting band-aids over things?

Dave [14:58]: I really... I mean, this all comes back to not looking for an off-the-shelf solution, not looking for "this is the way we've always done it," but really having that conversation about what is a risk we understand pretty well that we can mitigate and work around and put controls in place, versus what are the risks that we have no idea are going to happen. But somehow we can build redundancy and resilience into our system, so we have ways of recovering even if something unexpected hits us.

Peter [15:27]: Yeah, there's this idea of understanding the system of work as well. What are the failure modes of the system? Anytime you see something that gets traced back to being "human error"—look at why that human was able to make that error. Because the fact that they were able to do that is the actual problem. It wasn't that the human necessarily made an error. It's like, what could you do to actually reinforce the system itself so that the person doesn't make the mistake?

There's this book, "The Field Guide to Understanding Human Error," I think by Sidney Dekker, and one of the first stories he tells is of a new type of plane taking off. What they discovered was that just after takeoff, a lot of these new planes were crashing, and initially it seemed to be human errors because basically the pilot would say to the co-pilot "raise the landing gear" and all of a sudden the plane would crash. On investigation with the black box, they discovered that for the co-pilot, there were two switches next to each other. One of them was "turn off the engines" and the other was "raise the landing gear."

Dave [16:40]: Two switches next to each other? Yeah.

Peter [16:42]: So the simple solution was just don't have those two buttons next to each other. Fundamentally, when you're looking at safety and systems, you need to think about risk and resiliency in a way where you understand why did the system fail? Spend the time to go back and look and learn. What did we learn from this? What might we do differently next time to make sure the right thing happens?

On that note, would you like to take us home wrapping up this conversation?

Dave [17:12]: You know, the intention as we stepped into this was to keep it quite tightly focused, and I think we've actually had one of those broad ranging conversations again. laughs A key takeaway, I think, is agile and risk are very well suited to one another, and it will depend on the implementation or how you focus your agile implementation. But there's a lot to be gained from just understanding that risk is part of the conversation. Agile is very well suited to navigating that, if we look at the entire definition, which includes continuous learning and continually using those hypotheses. That would be one piece.

And if I can throw in one other one, it's that one about culture and about recognizing things which are abnormal or unusual, and being in a culture which encourages and rewards people who call those things out rather than shutting them down.

Peter [18:06]: And I think this all does relate back... I think you can tie a nice bow around all of this. I don't think we drifted off topic as far as we might have. All of agile as a system for continuous learning and ensuring that as part of your delivery system, that continuous learning is baked into it, is critical to ensuring that you're handling risk in a good way. Because agile is encouraging those shorter iterations, it creates opportunities for learning and the faster we can learn, the faster we can react and the safer the system becomes. So it does all tie together.

Dave [18:45]: Another great opportunity to just share some ideas and explore a topic. So thanks again, Peter.

Peter [18:52]: Pleasure as always, Dave, and I look forward to next time. Till next time!

Peter [18:57]: You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital, agile and DevOps at scale.