Daniel Breston shares his thoughts on why it’s a misconception that ITIL is incompatible with other practices:
Practices such as lean, agile and DevOps can’t be successful without ITIL.
Each of them needs to go from idea to realization, be supported in operations and improved as required. IT Service Management (ITSM) is the only practice that forces the issue of going live with improvement and that involves ITIL.
So why the misconception about ITIL?
ITIL and, indeed, COBIT are looked at by some as “heavy” frameworks that demand you implement it their way when, actually, you are free to adopt and adapt. There is also a perception that ITIL is operations-related, handling only the support side of IT rather than strategy, delivery, making the business better and focusing on the customer. This is the result of looking at service design from an architecture perspective only.
Some perceive ITIL’s approach to Continual Service Improvement as very process-oriented and don’t necessarily recognize the key metrics to work better, faster and safer.
Meanwhile, DevOps is seen as lean, mean and agile; DevOps conferences are considered cool, with great speakers. While that marketing is very effective and hard for other practices to compete with, people forget that DevOps is based on ITIL. You cannot do DevOps without service management and more people are starting to listen to this. In fact, the top five issues involving ITSM and ITIL introduction apply equally to DevOps and Lean.
And what about Agile? The community doesn’t see ITIL as a friend as its “I code, I test” approach is not implied in ITIL. ITIL doesn’t say it needs to be separate people either – the actual design is for an organization to choose, and this is where roles are often confused with FTEs. One person can have more than one role, and their responsibilities (and rights) depend on the combination of roles. Coding and testing have different sets of responsibilities, but it is absolutely fine for one person to hold both roles.
If you summarize the themes of the ITIL guidance as strategy, design, transition, operations, improve, agile practitioners get it and should recognize that ITIL’s not restrictive.
ITIL and other practices are compatible and this is how:
- ITIL is easy to use in Kanban and great to blend with Agile to create important processes
- Put the typical IT workflow (products, updates, technical updates and fixing things that break) into a Scrum/Kanban board and break down the steps involved for each
- Now decide who does what, when and why? Log the work
- Give the activities names people relate to in a business sense
- Start to manage workflow and make your people better, faster and safer.
- DevOps loves ITIL because without ITSM practices how can you support what you’re creating?
- If the code breaks, what happens then? Just because you put stuff in the cloud it doesn’t mean there isn’t something physical to rely on like a data centre. So, at some point, you’re going to be “doing IT”
- Focus on creating products, but remember that products are a process and you need to get products live in a way that doesn’t hurt the organization.
And I’ve seen it work in practice. For example, we have a customer using ITIL that created continuous integration, delivery and deployment processes with no Change Advisory Board (CAB). No loss of governance and simply better, faster, safer ways of working. Yeah ITIL!
See our ITIL section for more information.
More blogs in our ITIL Misconceptions series
ITIL® Misconceptions: “ITIL doesn’t require any formal training, it is just common sense or a tool that will fix it all.”
ITIL® Misconceptions: "ITIL is for big organizations only
ITIL® Misconceptions: "ITIL is for infrastructure or production only."
ITIL® Misconceptions: “ITIL requires too many people.”
ITIL® Misconceptions: “ITIL is a standard to adhere to”
5 popular misconceptions about ITIL®: ‘ITIL is a standard’, and other folk stories
ITIL® Misconceptions: "You don’t need to worry about culture when adopting the ITIL framework."