The ITIL barrier to DevOps success
The DevOps movement has renewed excitement in the IT industry and began bridging the expectation gap between business, development and IT infrastructure teams.*
A common language is one of the biggest benefits ITIL (IT infrastructure library) introduced. With the introduction of DevOps and agile delivery methods, we have lost that common language and the resulting confusion has become a barrier.
Training programs that introduce IT staff to the DevOps practice and encourage the reading of foundational books on the topic are a great way to start bridging the language barrier.
Another option similar to ITIL is to consider certification training for your staff in the DevOps Foundation course accredited by the DevOps Institute. This will ensure everyone has a common understanding of what DevOps is and, most importantly, what it is not.
In some organizations, ITIL processes have become highly bureaucratic and process assurance-centric, adding fuel to the DevOps vs. ITIL battle. There are simple, practical ways you can evolve your ITIL implementation to support your DevOps practice.
The two most common myths about DevOps are that DevOps will replace ITIL and that ITIL processes do not support DevOps. Let’s debunk these myths and provide some practical ways you can start to adapt your ITIL service management (ITSM) framework to accelerate, not hinder, DevOps implementation.
Myth 1: DevOps will replace ITIL
DevOps is not a standalone framework, a standard or a methodology. It leverages multiple frameworks, methodologies and standards including ITSM (e.g. ITIL), Agile (e.g. Scrum) and Lean (e.g. Lean IT).
DevOps is primarily a change in how IT operates. The essence of the movement — using an acronym developed by John Willis, Damon Edwards and Jez Humble — is CALMS:
- Culture – People and process
- Automation – Automation to improve flow
- Lean – Remove waste
- Measurement – Quantify, then track improvements and success
- Sharing – Increase, amplify and shorten feedback loops
DevOps implementations require the other frameworks, methodologies and standards you use in your IT organization to evolve and adapt to the DevOps values.
DevOps is not prescriptive, so there is a lot of varying definitions of the principles and practices.
The philosophy (also referred to as principles) of ‘Three Ways’ was introduced in The Phoenix Project. At a very high level, it can be described as follows:
- The First Way – Increase flow with the whole system
- The Second Way – Increase, amplify and shorten feedback loops
- The Third Way – Continuous experimentation and learning
A summary of the underlying DevOps practices that enable the principles are:
- Continuous Integration – Integrate code into a shared repository on a daily basis
- Continuous Delivery – Ensure software is always in a releasable state throughout its lifecycle
- Continuous Deployment – Auto deploy to production the changes that pass automated tests
Foundational DevOps Books
Some of the other tools, methodologies and techniques used to successfully implement DevOps include: the establishment of cross-functional teams, use of the Deming Cycle or PDSA (plan, do, study, act), Kanban (Toyota's production systems), Improvement Kata (Toyota Kata by Mike Rother), various vendor-specific DevOps tools that enable continuous integration, delivery or deployment through tool automation, and other DevOps-inspired vendor tools and solutions.
Myth 2: ITIL can’t support DevOps
ITIL is a framework, not a prescribed set of processes and procedures. Every organization has implemented the ITIL framework in unique ways to suite them, primarily influenced by their risk appetite and IT team’s performance targets. Over the years, some companies have evolved their ITIL processes to be more process control and assurance-centric. There are elements of ITIL that lean towards a waterfall approach but it can be evolved to better support agile delivery and DevOps.
The best way to adapt your ITIL processes to embrace agile delivery and a DevOps practice is to first review and update your process KPIs and SLAs. What you measure and how to define success has a significant impact on behaviour and the sub-cultures that form in organizations. It is also the ‘M’ in CALMS.
Start with your change process. The DevOps ‘Three Ways’ philosophy is all about continuous experimentation and learning. When you have an ITSM team accountable for ensuring all changes are successful and the dev team is accountable for speed and agility, you get a conflict of interest.
The most common change KPI is percentage of successful changes. Consider replacing this target with KPIs like the following:
- Successful rollbacks – If a failed change is detected early and rolled back with no or minimal disruption to users, is it really that important that changes are successful? To encourage a culture of continuous learning, the performance measures have to allow a degree of experimentation without fear of failure.
- Quarterly improvement in number of automations introduced (automated rollbacks, automated changes, infrastructure as code, process automation/simplification, etc.) – When both teams are encouraged to increase automation and simplification, you create shared interest. It’s in everyone’s interest to ensure automation changes are approved.
- Quarterly improvements in percentage of pre-approved changes – In ITIL, pre-approved changes are, in essence, standard changes. The term standard changes, however, is not well-understood. My preference is to create a change type called ‘automated changes’ or ‘pre-approved changes’ and measure both teams’ success on the number of changes that are ‘pre-approved.’
- Customer feedback on changes – If the user community perceives a failed change as successful, is it a ‘success?’ Use feedback from the consumer of the IT service to assess success.
Some other tips you may want to consider:
- Embed ITSM staff to your DevOps team
- If you use Scrum, recognize the role of the product owner in the change and release process.
- Empower the product owner to authorize changes/releases
- The product owner may be required to seek endorsement from defined stakeholders before making this decision in the beginning of your journey
- Empower the product owner to authorize changes/releases
- Consider changing the role of some of your change advisory board (CAB) members to technical peer reviewers, and then encourage your DevOps team to seek peer reviews or embed them directly in the team.
- Consider using an agile delivery method to execute your ITSM process and procedure changes. The main benefit is to get the service management team actively engaged in agile delivery and bridge the language barrier. It lets them experience agile delivery in a process context. For example, the Certified Agile Service Manager course accredited by the DevOps Institute has adapted Scrum to implement process design and process improvement changes.
*I use IT infrastructure teams vs. IT operations because a lot of organizations leave out the IT service management teams, causing an unexpected rift, creating silos and increasing apathy; all of which make it harder to get full value from a DevOps implementation.