Agile: Dealing with ITIL/CAB

Let’s get something clear right off the back. CAB stands for Change Advisory Board and not some almighty Change Acceptance Board as implemented in some organisations. The ITIL Change Manager has the mandate to refuse changes to be deployed based on the advice from the CAB or even allow changes against the advice of the CAB.

Disagree? See Link.

According to ITIL all changes should go to the CAB. This is generally accepted to be ridiculous! In any sizable organisation the CAB will never be able to review all changes. If CAB cannot advise on all changes, should it advise on any? And, if so,on which ones? How does CAB fit into a fast changing Agile methodology like Scrum or Lean?

Judging from history, Agile teams following a bi-weekly cadence deliver anywhere from 10 to 40 stories per Sprint. This is too much for any CAB to process across multiple teams. 

Another concern is that agile teams move much faster than CAB who typically, at most, meets once a week. Waiting for CAB to review and advise on every change will create a huge backlog of Work In Progress (WIP) and Agile teams hate maintaining WIP. It creates parallel code branches and exponentially increases complexity.

However, some organisations are not quite ready to let go of CAB and to be honest, they can play a valuable role in the workflow.

We just need to be practical about what goes to CAB for approval. Being pragmatic, our teams have adopted a process to manage and internally approve all changes and only send changes to CAB that may affect external systems or projects. “External” in this case means external to the team. For instance, if the solution feeds data to another system and that feed is affected in any way then CAB is notified. It is still the team’s responsibility to coordinate with external teams beforehand about these changes and the CAB process should not be relied on for this. 

So, any change affecting any external system should be reviewed by CAB.

But, in a self-managing agile team who is responsible for this?

Tada! In steps the much overlooked role of Release Manager. Agile work still needs to go through a release process to get into production and development is not done straight onto production systems as some popular myths would suggest.

The role of the Release Manager in an Agile team is to build a release, verify quality of the new deployment and release it to production. It is also the release manager’s job to notify CAB of any changes that may impact other systems or projects. Anything not affecting any other system or team is OK’d by the Release manager.  In other words the Release Manager approves "internal" changes and the Change Manager (Chair of CAB) approves "external" changes.

In conclusion, even though CABs were originally established for infrastructure changes and still mostly focus on those changes, the construct can be well applied to software deployment in an agile environment as long as the boundaries are well defined and adhered to.

Also See: Agile: Dealing with PMPs , Agile: Dealing with SMEs