Kill the CAB (Change Approval Board)

Dave and Peter discuss Change Approval (or Advisory) Boards. They are a crucial component to organizational change and managing change with companies. As organizations starts to adopt Agile, responsibility of change shifts into the team level and the Board becomes a facilitator to change.

Resources:

Better Value Sooner Safer Happier - Jon Smart
https://soonersaferhappier.com/

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

Chapters

• 0:00 Introducing the CAB Kill Topic
• 4:16 Change Approval Evolution in Organizations
• 8:13 The Culture of Safety Challenge
• 13:30 Risk Management and Application Tiers
• 17:45 Safety Teams and Final Thoughts

Transcript

Peter [0:07]: Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale.

Dave [0:16]: Morning, Peter! Great to be back here chatting with you about one of our favorite topics - and by "favorite," I mean it makes us want to pull our hair out sometimes. We're talking about Change Approval Boards, or CABs, and what role they should actually play when organizations try to become more agile. So maybe you want to kick us off - what do you hope to see happen to these boards when agility rolls into larger organizations?

Peter [0:47]: laughs Well, good morning Dave. You put that way more diplomatically than I did when we were talking earlier! I basically said "just kill the CAB. Kill it dead." But that's... okay, that's a bit clickbait-y, because we both know it's more nuanced than that.

What really needs to die is the CAB's current function - being the gatekeeper of ALL change into production. You know, that whole "thou shalt not pass unless you get sign-off from these 10 VPs" nonsense. It's incredibly ineffective, slows everything down, and completely kills the fast feedback loops we need for modern software development. So that function? Yeah, that needs to go. But there are other roles a CAB can play, right?

Dave [1:45]: Hold on, before we even talk about killing the traditional CAB, let me ask you this - in your experience, what does the Change Approval Board actually morph into in organizations where they're still critical to getting stuff out the door?

Peter [2:16]: Oh, that's interesting. So what I've seen happen over the years, especially when organizations start adopting more agile and DevOps practices, is that the CAB's involvement in every single change becomes... well, less necessary. We start shifting that responsibility away from this central board and pushing it out to the actual teams - the people who are way closer to understanding what the change actually is.

So what happens is the development teams and their managers just... stop showing up to CAB meetings. Because there's no need! But there are still other types of changes that get discussed - usually the big, scary ones. Like when we're swapping out core networking switches or something that impacts everyone.

That's where CAB becomes more of an information radiator, helping facilitate and coordinate these massive, complex changes that touch multiple teams. It's a completely different role.

Dave [3:41]: Yes! That's exactly what I see too. As soon as I hear about formal release management or change management processes in an organization, it never takes long to discover there's actually a dual track system running.

There's the main track for the big, expensive, high-impact changes that need formal coordination. But there's always this backdoor that the delivery teams have figured out - they know exactly what they can sneak through the backdoor and what has to go through the main process.

It's like... mammals versus dinosaurs, you know? You've got these quick, nimble mammals running around making small changes, while the big, monstrous changes still need all that coordination. The question is how do you bring those two tracks together properly?

Peter [5:10]: Exactly! And this is where the DevOps world has given us so much insight. When you really dig into it, the question becomes: why do we care about change approval at all? What are we actually trying to accomplish here?

When you peel back the layers, it usually comes down to one of two things. Either someone decided to adopt ITIL word-for-word and said "we must have a CAB" - even though modern ITIL has moved away from that rigid interpretation. Or, and this is the big one, something went horribly wrong at some point because somebody made a change without understanding the impact, everything broke, and now everyone's scared. So they're like, "Nope, can't let that happen again. Approval for everything!"

Dave [6:17]: Oh man, that historical element is so important! There's always some ghost of 1992 haunting these processes - "we tried this once and it went sideways, so now we need seventeen approval steps."

And look, that's often the right response initially. When something goes wrong, you need to add process and checkpoints to learn from it. But the intention should be to ease those restrictions over time as you professionalize the process and build better safeguards.

The problem is that the board's supposed role - validating changes are done correctly and all necessary steps are met - falls apart when more and more work is going through those backdoors to avoid the delays.

Peter [7:22]: Right! And as we shift toward smaller, more frequent changes happening all the time, we want to absorb those approval processes directly into the delivery practices. That's what DevOps is really about - consistency in configuration management, deployments, being able to move through that process safely.

But then there's this whole other layer of complexity. I've been having conversations lately about accessibility, information security, DevSecOps - all these critical areas that can absolutely trip you up if you're not careful. How do you get those practices embedded directly into the delivery teams instead of having them be external gatekeepers?

Dave [8:47]: Oh, that's fascinating because this is actually one of my favorite conference topics! laughs

So here's the thing - we have all these practices that seem completely orthogonal to the actual delivery stream. We want changes moving through the pipeline as fast as possible so we can get feedback and accelerate learning. We want as few obstacles as possible.

Then along come audit, compliance, architecture, accessibility, security - all these things the organization absolutely needs to handle properly. And they're not optional! We need to protect customer data, stay within architectural standards, not introduce components that'll cause problems down the line.

The challenge is creating what I call a "culture of safety" where we're building these considerations directly into how our platforms work and how our teams think. So they don't have to stop everything and call up Bert in compliance...

Dave [10:23]: laughs Poor Bert!

Peter [10:57]: Exactly! They call Bert and he's like, "Oh yeah, we have something about cloud computing. Here's a 200-page document - the standard is in there somewhere."

So your delivery team has to dig through all that, figure out how it applies to their specific context, and try to determine if they can do what they want to do. There's this massive gap that needs to be closed.

I work with teams to change how they talk about these things - giving them language that the safety organizations understand too, so there are stronger ties and better communication.

Dave [11:42]: I had a conversation earlier this week that really struck me. This organization understood they needed to reduce the influence of their change management process - they got that if they were going to deploy as frequently as the business needed, the old model wouldn't work.

But what impressed me was that they weren't defensive about it. Instead of taking that "thou shalt not pass" Lord of the Rings approach, they flipped it around and asked: "How do we educate the delivery teams?"

First step: education. When you're making these decisions, understand the consequences. Here's what you need to know. And honestly, that's one of the beautiful things about agile delivery - everyone gets better at understanding all the connections because those consequences come back to you really quickly.

But then there's the second piece: risk management. The "thou shalt not pass" approach is this all-or-nothing risk management, right? What if we could say "these areas are lower risk, maybe we can police them automatically in our pipeline, so they're more amenable to continuous change. But these other areas? Yeah, we probably need to bring in the experts."

What's your experience with having those risk-level conversations?

Peter [13:48]: I usually start organizations with three categories that we can almost always agree on. First: internal, non-PII applications. No personal information, minimal damage if something goes wrong. This should be our experimentation playground.

Second: internal PII applications. Not customer-facing, but they have critical data that needs protection.

Third: the top tier - externally facing applications that access PII. These are the "make damn sure nothing goes wrong" category.

Once we understand those levels, we can talk about what our processes and organizational approaches should be for each one. What are we allowed to do, and how do we know which level we're dealing with?

I've seen some really innovative approaches in modern, greenfield infrastructures. But when you're dealing with legacy systems that are basically bubble gum and duct tape holding together a million different COTS applications that have been customized beyond recognition... sighs that's a bit more complex.

Dave [15:35]: laughs The technical debt hairball!

Peter [15:39]: Exactly! So I start with that simplified model, then introduce something I call TACO - Traceability, Access, Compliance, and Operations. The point is to create something that's easy to remember and understand, so teams can collaborate on it.

Instead of having to wade through 3,000 lines of compliance checks, they can ask: "What risk level am I working at? Have I covered all these different areas? Am I good to move forward?" And if something falls outside that framework, they know to talk to the safety folks. But now they have enough information to make some of those risk management decisions closer to where the work is actually happening.

Dave [16:56]: I love that you're adding the meat to the bones here! You're covering the education piece - understanding what we're looking at - and the TACO framework gives context around the different responsibilities. Plus the risk management you described.

But let me flip this around. Two things bubble up for me. First is timing. That "thou shalt not pass" model happens at the very last moment when a change can be stopped. That's way too late! We want these conversations happening much earlier, when we're creating the solutions, so we can start cleaning up those spaghetti systems according to better principles.

The second thing is... it's like asking permission from a teacher. What I'm curious about is how you get those compliance officers and regulatory folks actually involved in what the teams are doing, rather than just being the "yes you can pass" or "no you can't" gatekeepers?

Peter [18:44]: Oh, I love this! My favorite approach right now is having safety teams aligned to the value streams that delivery teams work on. So you have expertise across compliance, architecture, security - all the different areas - and their role is understanding the risk levels of what teams are doing.

They engage frequently with teams doing higher-risk work and much less frequently with low-risk stuff. Like, if you're updating the cafeteria menu, maybe they check in once a quarter. But if you're changing the account management system? They're talking to you daily.

Dave [19:54]: Is that safety team directly involved in the solution design? In that high-risk example you mentioned - modifying customer accounts and information - are they actually part of creating the solution?

Peter [20:09]: Absolutely! Right from the beginning. They help guide the initial solution and support the team with questions along the way. Jonathan Smart has some beautiful ideas about this in his book "Better Value Sooner Safer Happier," and there's a great YouTube video he did on culture of safety that I'll link in the show notes.

Dave [20:44]: That sounds perfect. Okay, we're running up against time here, so let me wrap this up. We started with your very provocative "kill the CAB" statement - and I'll note that I didn't suggest killing anything or anyone during this conversation! laughs

But seriously, if someone's currently part of a Change Approval Board, what's the key conversation they should be having to start moving in this direction?

Peter [21:21]: For me, it comes back to those classic DevOps and Agile principles - inspect and adapt. Ask yourself: what value are we actually adding by doing this? How can we help facilitate change instead of being gatekeepers? How can we play a more strategic role in smoothing the path to change, knowing that we need to make changes quickly so we can learn faster?

Dave [21:47]: And I'd add that part of that inspect-and-adapt process is recognizing those two tracks we talked about. That informal track often isn't aligned with the CAB's stated purpose, so there's a risk management opportunity to understand how much more work we can safely send through that fast track.

Plus, there might be remedial actions we need to take - education, risk understanding, some of the ideas we discussed - to bring that informal track above board and make it more compliant as we go.

Peter [22:32]: Yes! And honestly, we could dig so much deeper into all of this. Thanks for another great conversation, Dave. Really enjoyed it as always.

Dave [22:42]: Same here, Peter. Until next time!

Peter [22:46]: 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.