How to Run a Change Advisory Board in a DevOps World

Hopefully, we all know that – in IT service management (ITSM) – change management (now called “change control” in ITIL 4) is the practice, or capability, that helps organizations to manage IT (and potentially business-impacting) change effectively, efficiently, and safely. Done well, change management (or control) can be a valuable part of your ITSM offering; enabling transformation while maintaining service stability. But how should what’s commonly an ITIL-based ITSM change management approach, and the change advisory board (CAB), work in a DevOps environment?

This blog looks at how you can integrate the ITIL-based CAB into your DevOps environment, in particular in a way that supports flow rather than being a blocker or source of conflict.

Getting some perspective on the DevOps versus ITSM debate

Much is made of the differences between ITSM and DevOps. For instance, I’ve heard that: one is all about value and managing services, while the other is all about speed and responsiveness. This is probably an ITSM-er view, because I’m sure a developer would also say that DevOps is definitely about delivering greater business and customer value and better managing production applications (or services).

Thus, the reality is that there are many similarities between ITSM and DevOps. Both are concerned with improving customer experience and both aim to take IT services (or production applications) and outcomes to the next level.

Importantly, we should be thinking about ITSM AND DevOps rather than ITSM OR DevOps.

10 tips for blending the CAB into DevOps

There are many advocates of DevOps that see the CAB as something that is harmful to change and business operations. On the other hand, many ITSM pros see it as a necessity in ensuring that critical and/or risky changes are handled with due care. In my opinion, both views are valid in certain scenarios and the key is to use a CAB capability only when needed – this is the first of my 10 “CAB blending” tips:

1. 1. First and foremost, NOT EVERY CHANGE NEEDS TO GO TO THE CAB! Have I got your attention yet? Sorry for shouting, but in all seriousness, no one needs to see a change request for activating a network port or the reboot of a test server out of hours at a CAB. Only use the CAB for the serious stuff, the changes that will have a significant impact on the organization.
   2. Getting your people on board is everything. Switch up your teams so that your DevOps organization has people with an ITSM background and consider tweaking the role of some of your CAB members to technical reviewers so that peer reviews become quicker and easier.
   3. Use models and standard changes to free up the CAB. Change models are a set of predefined steps such that if the nature of the change is known and understood, it should be able to be approved outside of the CAB. Standard changes take this a step further by having pre-approvals in place for low risk, tried and tested work. Delegated authority capabilities can also be used to reduce the load on the CAB and to increase flow.
   4. Make everyone responsible for their work. No more silos or “them” versus “us” anymore, just one team. And make sure all work is peer reviewed before it can progress.
   5. Lean into automation. Integrating the DevOps toolchain and pipeline with your ITSM tool such that notifications can be sent to the relevant participants and stakeholders at key points in the pipeline. This will enable approvers and technical reviews to respond to decision points efficiently and without having to wait for a CAB meeting to be convened.
   6. Use automation to build in decision gates between significant steps such as “release to production” or “wait for CAB authorization” when appropriate. This will ensure that the change has the appropriate sign offs without introducing delays into the approval process.
   7. Use kanban boards to keep things visible and changes on track. This will enable your teams – including the CAB – to visualize work, limit work-in-progress (WIP), and maximize efficiency and flow.
   8. Only convene a CAB when needed. There’s nothing more frustrating than having a packed work schedule only for one of the meetings to not add value or to be consistently canceled at short notice.
   9. When a CAB meeting needs to happen, ensure your attendees have the list of the proposed changes ahead of time so they can review them and make a note of any questions or concerns. This includes the identification of changes that shouldn’t be going down the CAB route.
   10. Keep your CAB on point. If all the prep work has been done, and the list of proposed changes has been circulated in good time, then representing a change should take one to two minutes. All that’s needed in most cases will be the person representing the change to give a short overview of the work being planned, highlight any risks, and confirm that the right testing has been carried out. If you find that people are taking too long to present at the CAB, then have a rule that if a person overruns then the next time they present at CAB they can only present for as long as they can hold the plank position. Who said change management can’t be fun? (Okay maybe not the plank but something that ensures they hurry along.)

The 6 benefits of taking a blended approach

Taking such a blended approach will allow your organization to get the best of both approaches when it comes to change. For instance:

1. Increased output – because following a continual release model means that software is deployed in a way that can quickly flex and respond to the needs of the business.
2. Responsiveness – if a change isn’t progressing, then – thanks to kanban boards – it’s visible to all; enabling the right action to be taken before things spiral out of control.
3. Visual clarity – again thanks to kanban boards, all participants and stakeholders can see a visual representation of a change as it progresses through the approval process.
4. The power of DevOps’ automated capabilities – and the increased use of automation increases speed and reduces the potential for error.
5. A better balance of speed and risk – the change queue is more controlled, hand-offs are briefer; and pull-based systems expose any process inefficiencies, delivery issues, or lack of clarity.
6. The opportunity for continual service improvement (CSI) (or “continual improvement” if you’ve already aligned to ITIL 4) – the CAB becomes a platform for improvements because a more-agile approach makes it easier to identify and fix issues as they arise instead of reacting to issues later.

Have you successfully blended a modified CAB into your DevOps environment? Or have you still found it too cumbersome in a DevOps world? Either way, please let me know of your successes, and issues, in the comments!