ITIL, Agile and Change Management



Stage 2

Agile IQ® Level






The ITIL 4 Change Enablement practice introduced the idea of responding differently to varying levels of complexity of change, from the routine to the catastrophic. It also recognises that traditional change control committees act too slowly and delay the delivery of value.

In product-focused organizations, job titles and job roles are not typically adopted for Change Enablement, as this practice is integrated in the day-to-day activities of product development teams and is automated wherever possible.


Change Advisory Boards (CAB) and Agile

The idea of a CAB is de-emphasised under ITIL4 by the Change Enablement Practice. 

Changes require resources and introduce risks. This sometimes leads to organizations establishing complicated, often bureaucratic systems of change authorization, with formal committees that meet regularly to overview and authorize changes accumulated over the period. These are known as Change Advisory Boards (CABs). CABs often become bottlenecks for the organization’s value streams. They introduce delays and limit the throughput of Change Enablement.


The idea of the CAB has been, for the most part, replaced by the  “Change Authority”. This is due to: 

  • The extensive documentation required to formally define any change.
  • Waiting for a CAB meeting to approve a change.
  • The delay in delivery of value that waiting causes, particularly when pivoting rapidly to disruptive change is often business as usual.

The CAB concept in ITIL4 has been replaced by criteria in the Definition of Done:

  • Code and quality standards.
  • Peer reviews.
  • Automated testing and authorisation.

Empowering teams to make changes

ITIL4 empowers teams to make changes through standardised events:

  • Daily Scrum – to approve team-level changes.
  • Sprint Review and Sprint Planning – to approve product level changes.

Empowering Product Owners to authorise change and releases

Depending on the scale of the change, ITIL4 also empowers the Product Owner or a product Manager (SAFe) as the role to authorise major changes.

Those that authorise changes under ITIL4 are called Change Authorities.

Change Authority

In high-velocity organisations, it is a common practice to decentralise change approval, making peer review a top predictor of high performance.
For example, an agile product team would make decisions on which elements of the product backlog will be tackled in a Sprint, while the Product Owner would make decisions on which customer requirements would be included into the Product Backlog.
Organisations adopting DevOps typically establish systemic approval based on the success of automated checks in the continuous integration/continuous deployment (CI/CD) pipeline.

Change Enablement

New ITIL 4 practices reinforce team’s needs to manage software and product changes through:

  • Conducting safe-to-fail experiments, automation, and peer reviews whenever possible.
  • Making changes smaller, thereby decreasing the risk you introduce into your environment.
  • Writing change requests through User Stories (PBI)
  • Using “Product and Sprint Backlog management tools” to capture, prioritise, and manage both changes as well as improvements to the practice itself.
  • Using Kanban to capture and plan for changes, which makes the work visible.


1. ITIL4. Axelos.

search previous next tag category expand menu location phone mail time cart zoom edit close