ITIL is a set of guidelines that, in previous versions, created processes based on IBM’s 1980s library for the best ways to manage an IT department.
Since the 1980s, it’s evolved into a formal framework for good practice. Importantly, the framework has shifted from being IT-centric to integrating closely with business outcomes. In 2019, the framework’s focus is now on co-creating value with the business. It’s this new focus, from pre-defined processes and committees to approve system changes to value that also aligns with agile frameworks.
ITIL3 manages change through a process involving a number of checks and balances and a governance body called the Change Advisory Board (CAB).
The main function of the CAB in the process is to ensure quality operations and production throughout all changes. In its implementation, people often misconstrue CAB as a board that deals in approvals and sign-offs, resulting in additional documentation and red tape.
The ITIL 4 change enablement publication references the CAB as a bottleneck to an organisation’s value streams as it introduces delays and limits the throughput of technical changes.
ITIL 4 shifts to a focus on practices. This gives organisations more flexibility to:
Change can be initiated in a number of ways:
The structured process and documentation makes sure an organisation documents every change by identifying different levels of changes and specifying how to handle them. In ITIL3, some changes require minimal authorisation while others require a detailed report about finances, benefits, and risks.
While effective in documenting change, this process, however, is typically slow. It introduces delays and limits the throughput of change.
The main function of the Change Advisory Board is to ensure quality operations and production throughout all changes. In its implementation, people often misconstrue CAB as a board that deals in approvals and sign-offs, resulting in additional documentation and red tape.
The ITIL 4 change enablement publication references the CAB as a bottleneck to an organisation’s value streams as it introduces delays and limits the throughput of technical changes.
Change enablement and the change authority accountabilities replace the CAB.
Introducing the concept of a change authority means that people have more flexibility on approval. This is particularly important for agile teams who fix defects and undertake refactoring continuously.
Change needs to flow in order to align it to the business and to deliver value. The ITIL 4 version of change enablement calls out the fact that while a normal change can be triggered manually by raising a change request, automation also plays a part.
Used effectively, technology is used by agile teams to create an automated pipeline that supports continuous integration and delivery – enabling most steps of the change enablement practice to be automated. In this model, the agile team has delegated authority to continuously integrate.
Change in agile teams is managed through the Product Backlog. This provides the Product Owner the ability to continuously adapt the work of the team to prioritise and optimise the delivery of value. A change request last week might be the most valued item of work for a team, but today it might be something else.
To effectively manage change using ITIL in an agile team:
With an agile team typicall able to release changes continuously through automation, Sprint Review provides a formal opportunity for the Product Owner, the team, and stakeholders to:
ITIL v4 defines different levels of severity for change. Agile teams handle all change by:
Standard changes are routine and unlikely to be formally documented in the roadmap, but will be documented as Product Backlog items.
Normal changes and major changes are identified by the Product Owner and stakeholders and documented through both the Product Roadmap and Product Backlog items.
Emergency changes, while being urgent, are documented as Product Backlog items with additional documentation following after a Retrospective regarding:
“The management of [change] shouldn’t be siloed in leadership. The biggest mistake I often see in change management is that company leaders often fail to involve managers in the process to embrace, promote and facilitate the changes that need to happen.”
Paul Pellman, CEO of Kazoo
The role of Product Owner is designed to the an “Agile Product Manager” who owns the budget and is responsible for delivery and optimising value. This role and its responsibilities can conflict with the terms of reference of an ITIL3 CAB.
Documentation is critical for change management. Agile teams manage all of their work through items in the Product Backlog. Ensure that:
What quality standards are needed before a change can be released?
When teams adhere to the Definition of Done, all their work, by default, is potentially releasable. Rather than mandating that the Product Owner assesses that work is Done and then formally approves that work at Sprint Review, empower the team to continuously integrate their work (especially with the support of automation) and then “turns on” those features using Feature Flags (i.e., “release on demand”) when the Release Plan and Roadmap indicates its time to make those available.
Introducing the concept of a change authority means that people have more flexibility on approval. This is particularly important for agile teams who fix defects and undertake refactoring continuously.
Axelos (2022) ITIL® 4: the framework for the management of IT-enabled services. Online at: https://www.axelos.com/certifications/itil-service-management
All fields are required.