Software development changed fundamentally with the declaration of the Agile manifesto. The principles reshaped the Tech industry and they started to change business management practices as well. However, it became apparent that if IT operations keeps working the same way the success of agile projects will be limited.

Developers and Ops guys often had frictions already before the agile movement. With the accelerated development pace and the iterative way of working the clash of the two worlds seemed unavoidable. DevOps addressed this gap and it allowed agility to continue its march into the realm of IT Operations.

But will agility succeed to reshape IT operations completely? And if yes will it mean that agile organizations will skip ITIL?

Does IT Operations have to become agile at all?

Agile principles were originally formulated to enable software developers to achieve better results faster. But even DevOps and Infrastructure As Code is only covering a small part of all the service provision tasks. You could argue why IT operations has to become agile at all.

The Manifesto was a response to projects that failed despite extensive planning, design, documentation and strict project control. Developers claimed that those projects failed because plans, process descriptions, contracts and documentations were more important than to allow developers and customers to work together efficiently and respond to changing requirements quickly. Problems that you might have encountered in some IT operations projects as well…

Next to that if development start to move fast but operations is still slow and overregulated then product quality will suffer and it will still take long until new functionality becomes available.

Finally expectations on IT increased as well. Customers and executives with the experience of delayed IT projects and mediocre project outcomes have higher expectation on IT now. They expect to come up with new ways of working and to deliver better results faster. Especially when digitalization gets high on the agenda of every company.

Agility is the way forward for a high performing IT operations organization. But you cannot – and should not – translate the Agile principles 1:1 into operations everywhere.

Agile principles and ITIL, a match made in hell?

ITIL developed through the years to an extensive framework of processes. It covers most of the aspects of IT service provision by now. Although as a collection of best practices it has no formal compliance assessment system many real-life applications became rather complex, heavily documented and often strictly regulated. Not a good start to become agile.

Agile methods are excellent for complex projects of non-deterministic nature. Many tasks in Operations though are rather predictable and repetitive activities. You might think it is not exactly the type of challenges where agility excels….

Nevertheless, it is not a mission impossible for a good Ops team to apply an agile way of working. The approach will be different for activities that are not repetitive and predictable and for repetitive processes. There are many complex projects in Operations as well. The application of agile principles will be more straightforward in these cases.

The identification and implementation of a new Service Desk tool for example can be much more effective by using agile methods. Working with your customers on a daily basis will ensure a much better fit to expectations than trying to create the perfect requirement specification. Setting up different test environments with free trial versions provides you first hand experience just like A/B testing in development. Experience which you not necessarily gain from sales presentations. Starting to use a tool with basic functionality will deliver results much faster than implementing a tool with all kinds of modules and a wide range of functionality.

There are however plenty of opportunities to become agile even in the field of day to day operational tasks. Here it is more the philosophy behind Agility and it’s Lean rooted methods (like Kanban and Kaizen) that enables the transformation.

How can ITIL processes become agile?

Let’s take some examples to see how different the approach to agility can be.

Incident management

Incident management is fortunately quite agile already. It is fast, the priority matrix helps to organize work based on what is more important for the customer. It is iterative (as you can provide a workaround first) and there is close cooperation with the customer.

You can make it even more agile though if you respond well to exceptions. If you are too rigid in your prioritization you will hinder customers. No rule will help you to decide when not to enforce your priority matrix. You can empower (and train) your SD team instead to make the right decisions. I’m quite sure your customers will remember more on these situations than on how quickly you fixed a printer outage… Of course, you have to limit the number of exceptions but at the same time you should be prepared to respond efficiently when they happen. And as we all know they happen again and again.

Change management

Change management is a different topic. Standard changes are efficient recurring activities, the more tasks you can set up as standard change the better. Obviously, you can improve even standard changes further by automating more. Infrastructure As Code is our friend here. If you test your code well it will allow you to do better changes faster.

It is however the management of complex (called normal in ITIL for some reason) changes that really differentiates an agile Ops organization from a traditional one. Waiting for a weekly (monthly?) CAB meeting can be frustrating for a dev team. If DevOps works well then Ops, the customer and IT security are involved throughout the process. This way the aspects that the change manager or the CAB would evaluate should already be addressed in advance. Change management becomes a QA function rather than a gatekeeper. If your change manager gets bored despite the growing number of changes than you know that you are on the right path…

Service asset and configuration management

Asset and configuration management is a very different animal again. Most of the time it is invisible for your users and it involves your customers much more rarely than other processes. Efficiency is the key here rather than agility. You can improve it for example through the use of an automated discovery tool. If you resist to run this process in splendid isolation, if you automate your CMS step by step then this process will work just fine.

As you can see agility will impact every ITIL process differently. There is no one size fits all and the size and type of the IT organization will also make a difference. But while the path to agility might be different the goal will always be the same for every organization.

Does tweaking some ITIL processes make an Operations team agile?

Surely not. To become agile is a cultural transformation, agile methods are the results of the transformation not the other way around.

Agility has a lot of aspects. It means empowering teams to make their own decisions as well as decomposing complex problems to solve it in iterations. It may include working with your customer on a daily basis. Surely it means reviewing and learning from iterations and setting goals for even 2 weeks instead of 6 months. This is a major shift that doesn’t come easy.

Agility in IT Operations will allow you to perform better. You can use the redesign of ITIL processes to introduce agility but keep in mind that this is only a tool and not the goal. The goal is to produce better results faster and to respond to changes better.