Can ITIL ever be agile (in my organization)?

To figure out what the answer is, we need to unpack the question to better understand why you (or your colleagues) believe that ITIL (as used in your organization) is not agile, and what the impact of this situation is.

Most often, when ITIL and agile are being discussed together, it is about delivering things faster. It is less about teams and collaboration (this is where the DevOps discussion often comes in), or about improved feedback loops supporting continual learning and adjustment (which is baked into ITIL, but often ignored).

There are several common challenges relevant to these discussions I’ve seen in organizations that are using ITIL in IT operations. I want to say “using ITIL to manage their services”, but I can’t, because in a large number of these organizations anything that has to do with IT service management (ITSM) is limited to their IT operations team, and there is no end-to-end service management to speak of.

You might recognize some of these challenges from your workplace. When cited, these are often used as proof that ITIL is at odds with the agile mindset, as there is a clear mismatch of practices. And because “ITIL says so” in those 2000 pages of guidance, there is no way out or around.

Look at our how we manage our changes — it’s anything but agile!

This is one of the topics in ITSM receiving the most attention, ever since the concepts of continuous integration and continuous delivery entered mainstream — so for about seven years now. The common characteristics of a cumbersome (and often painful) change management process include:

• a Change Management Board (CAB) manually reviewing all change requests at bi-weekly or monthly meetings
• a long list of change approvers, often including people not knowledgeable about or impacted by a specific change in question
• a high number of emergency changes, used as a workaround to get work done in spite of the established process

There is always a reason why the process was designed like that, and in my experience, more often than not, the reason was noble. Nobody wanted to introduce delays, overload and confuse people, or force them to break rules. With some exceptions of course (but you need to wait for my memoirs for these).

What is true about the change management process, as it is with every other process, is that it can and should be improved over time. New skills, new technology, and an improved understanding of your customers’ needs all warrant a revision of the existing process — and this should be a continual process, rather than a series of big-bang changes over the years.

Let’s look at the “why”

The problem with the three characteristics mentioned above is that in today’s world, they are likely to work against the objective of change management — to become better at risk management. A manual review of all change requests introduces unnecessary delays. Involving too many people in the approval process extends these delays even further, wastes people’s time, and is likely to lead to oversights. The abuse of emergency changes circumvents the problem with the existing process, but often leads to an increase in unexpected downtime and an even more vague understanding of the state of the system.

All of these practices contribute to the continuing illusion of control, masking the brittle IT systems behind a blanket of false assurance.

If there is a business need to become better at change management, often in regard to the speed of changes (that is, become (more) agile in our context), it might be useful to “go back to the roots” and think about what were the expected outcomes of the rules and procedures that were introduced in the first place.

Why is there a CAB? Is it because people appointed to it want to feel important, or because there are conflicting priorities across products, services, and teams — and these need to be resolved in the context of business objectives and risks? When you rethink the objectives, then can these be achieved by other means, or can the CAB be streamlined to re-focus on what matters, rather than be overloaded with reviewing everything?

Why is there a long list of people who need to review the change request? Is it because people enjoy attending meetings and reading documentation, or is it because it is important to assess the impact of the proposed change on this service, on other services, and on budgets and timelines? Is a manual review process for technical aspects of the change the most efficient way to achieve the objectives, or could perhaps a streamlined delivery pipeline with automated quality gates help? Also, could service portfolio management help with better guidelines for budget planning and avoiding constant panic?

Can things be done better?

There are probably other practices in your organization that are associated with ITIL, but seen as difficult to fit in the agile paradigm.

According to ITIL, do you need to design an “ideal” process before introducing it to the organization? Nope. You can introduce a small improvement to what you have in place already — let’s call the result a Minimum Viable Process — making sure the focus stays on delivering more value to your customer, not on delivering more documentation (although documentation is useful — just don’t overdo it). Yes, the process will soon need other improvements. That’s the point. Continual improvement over big-bang idealistic attempts.

According to ITIL, do you need to assign (or hire) a separate person for each role in the process? Nope. The roles describe responsibilities which might be easier to understand if separated into logical groups (i.e. roles). Nobody cares what you call the person who assesses the availability requirements for new services, as long as you have someone in your organization who does do that, and you know who they are.

According to ITIL, does an IT technician need to see their tasks in different queues, based on the process of origin? Nope. For people who work with different types of tasks — some related to incident resolution, some to problem analysis, some to infrastructure management — constant switching between queues is likely to drive down efficiency and become a major source of stress. For example, is that P2 incident related task more or less important than figuring out how to solve this deployment pipeline issue? While tracking the progress of different tasks based on their category is still useful for e.g. team leads, introducing something like Kanban might be a major improvement to people’s daily work, and their well-being.

So can it? Be agile, I mean.

Having recently been re-exposed to the world of consulting, it is tempting to say “it depends”, because, well, it does. On the organization, that is.

Every organization using ITIL has their own unique approach to the “how” as a response to ITIL’s “what” and “why”. The challenge here is that often the “why” has been completely forgotten, and the “what” is being dominated by the “how” that was put in place years ago. That is — specific procedures and artefacts have become immutable goals, rather than flexible means.

The capability to continually revise and improve services, processes, and procedures — the “how” — is a key enabler for improving agility. The organization can support continual improvement only if they really understand their customers. Only then is it possible to assess improvement opportunities through the lens of increased business/customer value. Only then can they be agile.

So, perhaps the answer to whether ITIL can be agile in your organization lies in an answer to another question: can your organization ever be agile?

ITIL® is a (registered) Trade Mark of AXELOS Limited. All rights reserved.