Governance roles or Safety enablement

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, David Sherrick and Peter Madison. And so, hey, what's on the cards today, Dave?

Well, uh great introduction, by the way. Great to chat to you again. Um understanding when and where to bring governance into the process. I think that's what we really wanted to look at. Uh many conversations. Um I'm in the process of having these with a couple of our clients. There's uh obviously, if you're a financial services organization, for example, there is a need for governance, and there's a conflict between speed of delivery, increasing how rapidly things get pushed out into production, and the need for governance and risk mitigation and that management of the bits that are concerning to an organization before they go live, before a change goes live.

Yeah, and we we this this is always a balancing act because we we've got to both understand and manage the risk within the organization. We know we have potentially external um requirements to either external regulatory bodies or even to our own governance of the organization where we want to ensure that we've we're doing the right things with regards to uh securing and protecting data from our customers and making sure that we're not uh accidentally exposing data where we shouldn't. So we've got to have some forms of governance in place, but we've got to make sure that that governance practice isn't so overbearing that's impacting our ability to deliver.

And we want to avoid taking the approach, one of my favorite little stories that I love sharing every now and again, uh, working with a team that wanted to improve how you know, increase the frequency of release. And part of their governance process was performance testing. And so the way they proudly kind of got around this initially was they'll only performance test every fourth release. That's not what we're talking about. Removing the governance does not give you what you need, it's not going to give you speed long term, it's not going to keep you um uh able to compete, let alone probably in your job, if you start pulling it away. So, how do we start approaching it? How if if you've got a governance process, what can you do to allow the frequency of, let's say, deployment releases to increase exponentially without expecting that governance process to become uh um blocked through requests for approval.

So there's two uh pieces to this that I tackle, and this is something I do quite a bit. I mean, this is uh actually one of the major things I engage with organizations on. Um one of the one of those pieces is understanding how do we integrate the understanding of what's necessary into the system so the systems themselves can provide the information that's required out to the governance system so that we're collecting the right information while we're also educating the delivery teams on helping them understand what is necessary. And that then there's another piece where we need to look at this organizationally to put into place the structures and the frameworks to better align those uh those governance organizations or safety organizations is another way to think of them. The pieces of organization that are there to try and ensure that the safety of the system, to ensure that uh we're reducing risk in the system, and better aligning them to the delivery system so that the delivery system is able to properly manage and govern and uh the processes within it without interrupting flow and delivery in the process.

So, what I'm hearing you say, or at least a lot of what you're you're covering there, is is effectively uh reworking the system, whether it's the deployment pipeline or the systems themselves, so that there's sort of self-governing, or there's there's a lot of um you're you're using technology to automate a lot of that governance. Would that be right?

So that's that's one part of it. Uh there's another part of it though, too. There's certain aspects that we won't easily be able to automate into the system, especially when it comes to certain regulatory requirements or or checks or pieces that we need to ensure we do the right thing within the code. So for from that side, from a compliance perspective, uh it's instead saying, well, if this is my value stream, if this is the stream of work that creates value for my customers that I'm working along and my delivery teams are aligned to that value stream, I want to also look at my safety teams, my architecture teams, my uh compliance teams, my security teams, and I want to create a cross-functional understanding that's also aligned to that value stream so they understand what is required for that value stream itself to deliver safely. So rather than having, much as we've broken down silos within the delivery space, we need to break down silos within those safety teams too, so that there's but we create more of a common understanding. And we can do that through a number of mechanisms. Uh, but one of those is create these the cross-functional understanding across those teams. Uh, and we can also uh start to build out uh repositories written in language that is more in the context of the delivery teams are using to be able to take what we know as our body of knowledge and make it more easily accessible for the delivery teams so they can apply it more immediately to their work without having to pick up the phone, call uh reader Bob or Sue that and ask them a bunch of questions and try and interpret what the standard is to their needs.

So, as a in a in response to that, what I'm there there is an important extra element, right? So we're looking at at uh very clearly the the understanding of the the automation, the technology piece, which I think we'll come back to in a bit, but you're also talking a lot about uh the the education aspect. I I think there's there's there's sort of a mindset associated with many governance roles, which is I have the knowledge and you don't, therefore I have to be in a position to dot the i's, cross the t's, look at what you've done and critique it. And I think one of the things that I'd want to pick up is the whole purpose of governance is slightly different to that. It isn't somebody marking my work, if that makes sense. It and I don't I I want to be clear, I think there are many governance roles and teams and individuals and processes which aren't in that mindset at all. But sometimes you get that impression. It's a sort of a gate that has to be crossed. Whereas what you're describing, when you look at the need to deliver more quickly, to get into a flow and be able to get deploy changes safely, governance becomes an aspect of that safely. It's in order to get something out of the door, how do we make sure that we don't violate any of the responsibilities that we have to regulatory bodies, to um you know, to our uh security, information security and how we're handling things like that. And the way that we're going to do that is not to slow down delivery and impose a gate which we have to cross and check everything. Because if we go from one release a quarter to one release a day, now we have 90 conversations when we only had one before. It's unsustainable. But better is to understand how can we m build the pro that the changes, how can we help the teams involved in making those changes in a way where governance is implicit or the conversation is more of a handshake than it is a stop and search routine.

And uh exactly, because it's just as you can't install quality by inspecting at the end of the process, you you need to install process, you need to install quality into the process. Same with safety. So to put the understanding of this, you need to build it into the system, it needs to become part of how we work. So you've got to create that understanding and alignment within the teams so that the teams are capable of uh of doing a lot of this stuff for themselves, and exactly as you described it, so that it isn't somebody sitting in their ivory tower saying, Thou shalt do this, and uh or the the horror of uh the going to ARB or the multi-level ARB of like uh my immediate business sense, a technical review goes up to the global ARB, goes up to the uh and uh by which point you're nine months later and nobody's agreed that you're allowed to uh install JavaScript on your PC or something. It's uh it's just insane. Okay.

So what it what you're describing reminds me of um early days of DevOps, where the the process was going to the deployment team that was involved in deploying and looking at how they were deploying what that was there. And their headache was there was a lot of complexity in that deployment process. And the whole one one of the big conversations early on was was the need to refactor that deployment process to extract that complexity and and kind of put it somewhere else, either decouple it or or build it into other parts of the system so that that complexity is properly extracted, and now we have a deployment process which is repeatable and automated in a controlled way and doesn't have the one individual who knows where particular libraries are stored and all the other things that come together with that, right? But but um when we look at governance, it's a little bit the same. We have to look at the complexity of the system and understand which pieces require a deeper dive and knowledge and expertise around how changes are made there and which parts of the system really don't, and can be can be deployed relatively unhindered by any governance conversation, for example.

And and we were you were talking about this this earlier, is that that that relation of governance to safety and what we're really trying to do is ensure safety in the system. And if we look at this from a uh like a safety one, safety two world, this this idea that we spend so much of our time focused on what will go wrong and creating checklists to say, um, well, have you done your security check? Have you done this? And and it becomes a checklist, a tech, check, check, versus looking at, well, how do we do the right thing up front? How do we make sure that we're we're building that quality into the system and we we build the strengths? We know that when when it goes right, it's because it's not it's rather because we've doing a lot of the right things. If we focus on the things that go wrong, that doesn't actually help us get better. So we we rather than focusing on the things that go wrong, we need to focus on what things go right and make those right things happen more often, because there will always be the anomalous things that will occasionally occur and occasionally go wrong. So we need to strengthen up our ability to be able to consistently deliver well rather than focusing on uh well, what could possibly go wrong and creating a number of checklists which slow down our ability to uh validate what's happening in the system.

I think that's uh there's a um a lot of discussion around quality and the resilience of systems, which you're touching on here, which is that mindset shift of stop trying to stop everything and start understanding that it's it's more a case of how do you make sure that that you know we're doing the best we can and we're minimizing the impact of things that may or may not get through, uh, but then we're in a position where we're, you know, it's I actually like it because it's that shift towards a much more positive mindset of you know, how do we how do we do this as well as we possibly can, rather than we know you're gonna make a mistake, we just don't know how big of a mistake you're going to make.

I don't know. I I like this in the in the language when we start to talk about things in terms of enablement versus in talking about instead of talking about change management, we talk about change enablement. Instead of talking about uh uh safety management or risk management, we really want to talk about uh uh so safety enablement. Like how are we enabling the system to get better and stronger and faster and uh and uh that's that's where we we start to see the improvements by changing that even in changing that language, we start to talk about things in a more positive way and start to improve things and our interactions together too.

Now, something that's slightly in conflict with that, but I think is still really important, is it doesn't mean there is no longer a role for some sort of policing activity around the changes. And the reason I mentioned this one is I'm I'm just uh reminded of the fact that it in in uh in a political process when a law is made, the law is only as good as the policing mechanism that controls that law. Because I mean there are many scenarios on this one, but if you look at marijuana across many different countries over the last decade or two, there have been laws that very clearly state one thing, but the level of effort, money, time invested in the policing meant that those laws were effectively immaterial or at least considerably uh reduced uh in their efficacy. And I think the same thing is happening here. Those governance guidelines, there's an aspect where those governance guidelines to be followed have to be in some way validated in order that the teams will continue to put attention to them.

Yeah, and I I think that there is an element there of you don't dive in and saying, okay, we're just gonna remove all the constraints. Like we we exactly we're not gonna allow everybody to go do whatever they like, because that that just ends badly too. We've we've got to ensure that uh we're we're introducing in such a way that there's that that understanding, that education took a bit is coming along too, that we're uh otherwise there it will cause many, many more problems. If we're if we're if we don't have any guardrails and uh the and anything is possible, um you end up um putting stuff out you you end up going into the cloud without any proper understanding of clo of configuration, and then somebody opens up the whole thing and all of a sudden your customer data is spread to the four winds, um, which I hope nobody is doing these days, but it still happens.

So well, and but but this is that resilience piece again, right? There's a case of looking at something and saying, um and what is it that we measure? And we talked a little bit about not just saying things will go wrong, let's just focus on what we'll measure there. Uh it's almost the system behavioral tri you know characteristic behavior that we're able to look for. So we're seeing whether or not that policing role might be the system isn't behaving in the way it normally does, whatever that might be, as well as the system has the locks on the correct places, the doors and the windows are locked, versus you know, is is uh is there something unusual about how the system is performing compared to what it normally performs, how it normally performs.

Yeah, yeah, looking for anomalous behavior, is it still doing what I expect it to do, or is something changed uh in that performance? So so at the risk of uh of because I can talk about this topic for hours, it's one of my favorites. So uh if you were to sum this up based on all the things that we've we've covered, what were what three points would you want our semester to do?

I I wanted to tease out one, which I don't think we've fully teased out, which is the balance aspect. These sorts of changes aren't, you know, on Monday we're going to make these changes. It's a continuum of understanding how rapidly we can make those changes and it and the balance of there's there's work to be done before the change can happen. So that was one part that I think is really valuable to consider. Um the other element, and I I it's almost like this is where our conversations often start to just try and shift to the mindset is around um stop impacting flow. It isn't governance, it is not a flow impacting activity. It should allow the flow of work. If you're going to move to more and more and more frequent deployments, you cannot possibly be impacting the flow of how things get out of the door. So you have to work with it rather than put gates in the way and you know shunt shunt things off to the side while they're they're inspected before they go back into that flow pipeline, whatever that might be. Um the uh the other thing that I was just thinking of is, and this we touched on in a number of different ways, is uh that first line of the Agile Manifesto, um uh individuals and interactions over processes and tools. And we're talking about governance being replaced with some sort of technology, some automated processes and tools and some pieces there, but we also have to keep the people element in there, whether it's an education of the delivery team or making sure that the intake, the work going into the delivery teams are are articulated in such a way they understand their functional um responsibilities, they're the governance responsibilities, or whether it's that whole role of policing without policing that we just talked about, the kind of balance in terms of uh looking for anomalous behaviors.

Yeah.

Anything that I've missed or that you would add.

Uh the the other one that we I think uh, and I'm not sure we actually really touched on it as we were talking there, but we were talking about it before was uh the to get there, one of the kind of pre-constructs the the is to uh start to minimize dependencies that uh part of the reason that uh these the some of this bureaucracy often exists is because of the complexity of the system that's grown up. And so we have this this oversight, which is basically trying to uh manage this. So, one part of uh putting those guardrails into place is to start to look for how can we start to decouple the components of this so we can push them out into independently without having an impact on the web of spaghetti that uh is surrounding all of this. How can we look at one piece of this and uh determine how we can uh start to um innovate here and start to put the right piece into place here as a starting point to uh um cascade through the rest of the organization. So, with that, I mean I I think we've we've had a lot of uh good conversation, and uh I I think we could probably wrap up for the day. I'd like to thank you as always, and uh if anybody would like to reach out to us, they can at feedback at definitely maybeagile.com. And uh thank you again, Dave.

Excellent, good to talk again, Peter.

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.