ITIL4 and Agile
Advanced
difficulty
Stage 3
Agile IQ® Level
Change
Practices
ITIL
Framework
Introduction
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.
What's Gone?
Process are out. Practices are in.
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:
- Decentralise decision-making to reduce time for decision-making.
- Use self-management through guardrails to support team-level decision-making.
- Innovate to embrace modern ways of working such as DevOps.
Change Requests (RFC) and ‘Change’ Management
Change can be initiated in a number of ways:
- A formal Change Proposal through a business case.
- RFC form that standardises the information needed for a change.
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.
Change Advisory Board (CAB) is out. Change Authority is in
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.
ITIL4 and Agile
Change Authority and the Product Owner
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.
- Delegated authority – the Product Owner has the authority to determine when the best time is to release value and approve a release.
- Standard changes – the agile team has the authority to fix defects and release them into production.
- Peer reviews – the agile team reviews its own work and its adherence to quality standards as part of its Defintion of Done.
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.
Manage change through the Product Backlog
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:
- Change Requester: Document who made the request to make a change.
- Change Authority/Owner: Ensure the role description of the Product Owner encompasses their ability to ‘approve’ changes. Approval doesn’t need to be a formal sign-off as agile teams use their Sprint Planning event to move items from the Product Backlog to the Sprint Backlog.
Review change at Sprint Review
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:
- Assess the business landscape.
- Agree on what will add most value next Sprint and other changes to the roadmap.
- Consider changes to the release schedule on the roadmap.
Levels of change and the Product Roadmap
ITIL v4 defines different levels of severity for change. Agile teams handle all change by:
- Identifying when changes are forecast for release in the Release Plan and Product Roadmap.
- Documenting items in the Product Backlog.
- Agreeing that a change will be enacted by including it in a Sprint under the approval of the Product Owner.
- Ensuring all work is potentially releasable by adhering to the standards and practices outlined in the Definition of Done.
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:
- Why the emergency arose.
- How to avoid failure in the future.
“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.”
Things to do
Retire the CAB and empower the Product Owner to approve change
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.
- Be clear that the Product Owner is the ITIL4 Change Authority.
- Shift the ITIL3 CAB responsibilities to the Product Owner.
- Be clear about the collaboration and engagement that the Product Owner needs to undertake to create their Roadmap, document change, and what is required of them in terms of engagement when an emergency change is needed.
Manage change through the Product Backlog
Documentation is critical for change management. Agile teams manage all of their work through items in the Product Backlog. Ensure that:
- Change documentation needs are adequately met through the prioritisation and management of PBIs.
- Severity of the change is recorded.
- The area requesting the change is documented as is the value that the change represents to business stakeholders, the organisation, and its customers.
Define the quality that is needed for change through the Definition of Done
What quality standards are needed before a change can be released?
- Ensure the quality, audit and compliance standards are documented in the Definition of Done.
- Ensure that all work completed by the team is potentially releasable by adhering to the Definition of Done.
- Ensure all teams working on the same product use the Definition of Done as their minimum standard.
- Ensure that the Definition of Done is regularly assessed and potentially improved at the Retrospective, particularly when there is an emergency change.
Empower the team to release continuously through automation
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.
Engage with business stakehodlers on release management and change management
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.
References
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.
