Governance of software delivery value streams

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 today, Dave? I'm doing brilliantly. Thank you. I'm glad to hear it. So what's on the cards today?

Well, one of the reasons I'm doing brilliantly is I think we're in preparation for this, we were talking about the application of governance over, say, value streams or whatever we're trying to use governance with. And I think as we're coming through the notes, this is an interesting topic. I think it's so easy for us to either ignore governance or overthink governance in these contexts. And it's it's an important topic. You need some structure within which we're delivering the work that we're delivering. And we're working in a very dynamic environment. So that structure has to be able to handle ambiguity, uncertainty, and lack of clarity about what might be happening. So I think this conversation should be an interesting one. So how do you start us with that?

Well, when I when I look at governance and coming from the technology space, what we very often uh see is that governance is the burden we must bear because um auditors want to know whether we're doing the things we're supposed to be doing. And this gets interpreted um in like a DevOps context very often into sets of controls that get baked into pipelines. And I've helped many organizations adopt and understand how to align their um operational technology governance practices into pipelines and delivery. Uh but one of the things that I I've I've realized um over time is that there's actually kind of multiple layers of this. There's a layer of which is the in-process governance, um, which I use a model called Taco to kind of articulate this traceability access compliance operations in the pipeline, the things that we check for as we execute, um, the the piece of looking for there. But there's also a set of uh governance criteria that are outside of that. And I think that's where it gets interesting because these as we start to move at speed and we get better and better at our delivery processes and practices, the stuff that we use to manage risk within the delivery system itself is uh is important, but uh is there's also the uh the importance of the governance of the overall system becomes more and more so. It's like we start to realize that because we're making many, many small changes rapidly, that understanding how those influence the overall security architecture, for example, becomes a more critical aspect.

I I like the way you're describing that because it uh there's a couple of things that I just wanted to draw on. One of them is is, and I just want to pull this one out, that in-process and out-of-process governance is hugely it's a great distinction because too often we look at everything in process and we ignore out-of-process. And I think, of course, you you kind of need to balance both. The other thing is that we have to bear in mind that a lot of the out-of-process uh kind of governance requirements are the breaks on your speed of delivery. And so when you're looking at the out-of-process, if we ignore those, we're hemmed in in terms of the speed that we can achieve, in terms of go-to-market, whatever it is that we care about, release frequency and things like this. Uh, but equally, if we just look at those out-of-process things and say, well, if only they would wake up and realize what's going on, we're not building the bridges that we need. There needs to be that relationship. And how do I move or how do I get sufficient in-process governance to ease the out-of-process governance burden so that speed can really be achieved, what that balance is.

And that uh there's a piece there of making what's happening in the system visible so that I can consume it um out of the use of the system. But there are aspects like architecture and security and regulation and data privacy, which are very difficult to um necessarily bed into the system as a whole, and they're gonna vary based on what is it that I'm delivering, what is this value stream overall doing? Uh, and so there's lots of um there's variance in that, and uh, there's a needing to have an understanding there's not one size fits all, uh, and at certain points I maybe wish to be more prescriptive depending on what it is that I'm touching in that value stream, how critical is this component, how risky is this activity that I'm doing? Because I mean all of this kind of boils down to risk management, like it's this uh how are we managing risk?

But uh it it is very true, and that that's where sort of the governance mantra or sort of mindset comes from. Uh, but I wanted to pull out another piece that you're describing, and uh it really kind of strikes me as a shift, which is the governance becoming a lens or transparency into what is going on. So it's more about visibility than it is about control. I mean, there's definitely governance is about control for sure. There's an element of that, but that new piece or the additional, the sort of polishing off of the old dusty piece of visibility into that system. In complex systems, control isn't going to give you what you think it's going to give you. In fact, invariably, if you control in one area, it causes a lack of control in another area. So instead, you want that visibility over the whole system so that you can see how that system responds to various attempts at controlling or changes that you make to that system. So I think there's an important mindset shift there about moving away from uh a drive to control what gets done or make sure people follow rules, moving to one about visibility and empowering the people, the teams in that organization to use what they can see to make informed decisions uh in the pursuit of whatever it is that they're building.

Exactly. And uh I think the interesting piece is looking at well, how can we make something that is orthogonal to the value stream visible so that people can understand uh have we have we taken the governance steps that we need to without putting the brakes on everything by having arbitrary complex bureaucratic um processes like uh I'm looking at you, ARB, architecture review boards. So rather than manage things in in that manner, if we we can look at other ways. A good model for this is something like um lean control from the uh um BVSSH space. That's uh that's a great model for being able to look at uh how can we measure compliance at speed? How can we start to look at uh changing the way we consider these various different uh safety areas, if you like, and uh how they uh they need to interact more closely in the context of the value stream. So some really good ideas around how can we start to apply some of the same principles and logic and understanding to this governance space to create cross-functional safety teams that uh have a much stronger understanding of the underlying uh delivery of value.

It's uh I I kind of find it quite interesting as you start digging into this, because what you often find is I mean, most of the work that I I find myself involved with is really about process and in-process work, for example. And in the mindset that you often have there is you to ignore or to push off to one side an element of that out-of-process work. But as you change your mindset around how that out-of-process work operates, and I it is more like it's it's it's almost like it's the environment you have to work in in, and it's going to it's going to impact what you do, that out-of-process governance area starts touching some really interesting things, like we briefly talked about um in preparation for this, things like HR and recruitment, single points of failure, individuals who have knowledge about your system. Now, in a in a sort of traditional governance is out-of-process or in process, none of that is visible. And yet, as we start recognizing out-of-process versus in process and how they impact our ability to deliver things smoothly and quickly and confidently, we start looking at things like leadership changes and how that impacts priorities in the organization and that priority shift that can happen way outside our current process, what's that going to impact for what we're doing here? Or as I said, the I've mentioned a few leadership changes, single points of failure recruitment, things like that.

That one's a really interesting one when you start to unpack it as well, because one of the pieces that you see there is that, well, if somebody new comes into the organization because somebody else has left, and this person takes on the accountability for the approvals that they had before, they may not necessarily understand everything about the system that they're operating in and may approve things, which they possibly shouldn't. So there's this piece where we incorrectly assign a reduction in risk to the fact that we had somebody check a box, versus actually looking at, well, what is the risk of this actually occurring and quantifying and measuring that as a way of looking at the overarching system. Like so the we end up in these situations where you've got over time these business as usual checks that occur that everybody just agrees to and signs off on, or you end up with like escalation to somebody who's signing off on this occurring because they are nominally accountable because we've gone high enough in organization for them to be so, yet they've no real understanding of what is the risk of this this change or this or this activity that's about to occur. Um, I think this perhaps needs more time than we have today to dig into that particular one.

Well, but but maybe let me just close that one out before we dig too far into that, which is um, I think if we look at how we started, if I try and summarize where we were coming from, how we started is governance is is seen as that necessary activity that we don't really want to have to do, but we have to in order to work here. I think you described it as a burden on getting work done. And in the the course of our conversation, what we're now beginning to understand is it actually influences quite considerably how we do things like you know, what happens when personnel changes and authority is moved up and down, um, what happens with those in-process governance requirements, which are are really well documented and discussed and so on, versus those out-of-process requirements, which are often ignored or or kind of you know shoved into the corner somehow and yet are incredibly influential to the long-term stability and uh strength of the processes that we're working with.

Right. And and how do we, as we accelerate our in-process practices, our ability to go faster and faster and deliver more and more and more and smaller and smaller batches, and as we we get better at being able to do that and the value that that brings us, um there's it's we can no longer look at things in an individual um change perspective. We have to start to look at things in the aggregate of the scale. And that's why those other governance processes need to become much more robust, but also be able to go faster as well, so that we can uh understand their influence on the system and find ways to make that visible uh and apply it to our uh appropriate context. So if we're looking to sum this up, um, and I and I think we've kind of touched on quite a few different elements and uh where we so I'm gonna pull out two things.

One is the in-process, and you mentioned very briefly the Taco model that you use, traceability, accessibility, compliance, and operations. And probably that is worth, you know, like we'll put a link, go look it up. It's uh I I know you've spoken many times at conferences around that. So that in process, we didn't talk too much about how to go about doing it and so on, but there are models out there for it. I think we've ended up focusing on that out-of-process. And what's interesting, the the kind of key takeaways is one is that there are in-process and out-of-process governance, they're not kind of mushed together. Secondly, uh, there's a balance between the two. The out-of-process are often the breaks or the foils that will slow down delivery of in-process. So that there has to be a conversation and a kind of a general shift of burden from out-of-process to in-process to accommodate that speeding, speeding up we're looking for. Then the final point is as you look at that out-of-process, it extends beyond the kind of trivial thing, and they're not trivial, but the well-known things of privacy or security or uh architecture and so on. And they look at things, they start bumping into say personnel changes or authority and where that sits or shifts in priority, organizational priority, which can have a huge impact on our ability to get things done and manage those processes as well.

I I like that. I think it sums it up nicely. I think the the only the only piece I'd add is that we you know that you're going to have to show that um these processes are governed. So start to think about it, about how you can easily evidence this, make it continuous, make that visible uh so that when we we look at a process like uh architecture or uh security, that we we have ways of making that visible to the organization so that it can be consumed, so we can look at things and say, okay, we are in compliance, we are continuously in compliance, in fact. Um well, thank you for the conversation as always, Dave. It's uh this particular one's a favorite uh topic of mine. So and uh if anybody would like to reach out to us, they can at feedback at definitely maybe agile.com and uh I look forward to next time.

Until next time, Peter. Thanks.

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.