ITIL and agile are not always the best of friends, but they sure are not enemies

Agile service management means applying the agile mindset to IT service management, a concept that is as simple as that. Take into account, though, that this is not something that has often been done yet, and as simple as the concept may be, you will be pioneering the effort if you take it on. And even though at first sight, agile sounds quite opposite to the strict ITIL processes, they can work together pretty well.

The agile methodology is created with four foundational pillars in mind. The pillars are built on the core values of agile development, and need only a minor adjustment to also accommodate IT service management:

• Individuals and interactions over processes and tools
• Working software services over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

When following an agile service management approach you must keep to these pre-ordained principles when designing and delivering services, but used within an ITIL framework, there are some things to consider. While ITIL has been considered a gold standard of IT, ITIL nowadays is an old-school approach to most current service management environments that is not suitable in the business landscape, especially relating to ITSM. You can find evidence of this in the fact that this year there will be an ITIL update in which practical guidance on how ITIL is to be adopted in conjunction with agile also will be included.

Agile service management vs. ITIL

Is it possible to pair agile service management and ITIL? Compare the four basic values of the agile manifesto with ITIL and here you will immediately notice how opposite they are from each other: ITIL attaches significance to everything that the agile mindset believes to be less important. Individuals and interactions take precedence over processes and tools in the agile world – the 2001 manifesto is clear about that. Meanwhile, ITIL focuses almost exclusively on process descriptions and systems with a goal of creating quality of services offered. Here’s the catch: In an everything-as-a-service environment (world, more specifically), who supplies the service should and does not matter from a customer perspective.

There’s also the fact that ITIL methodology prefers comprehensive documentation. Additionally, ITIL guidelines fill five books with a total of 1,300 pages meant to explain the 26 ITILv3. Of course, you do not have to read and follow all of the ITIL processes, but needless to say, providing services within the agile framework will be less cumbersome.

Customer collaboration over contract negotiation

Contractual agreements are an important part of ITIL service level agreements, and creating these SLAs is a primary goal for many organizations where managers and their customers judge outcomes solely on these agreements. It’s clear to see when compared to agile environments that SLAs for SLAs sake can get in the way if these are the only parameters of success. In an agile environment it is key to make sure that if you have SLAs, they are there for the right reasons and they help you fulfil customer’s expectations.

Responding to change over following a plan

ITIL means planning, preparing for and responding with predictable processes based on the idea that solutions can be executed accordingly should the problem arise. The problem with the ITIL framework is that it can box you in so tightly that you are unable to divert from the plan should the need arise. The permanency of ITIL processes can be too watertight, leaving little way to deviate from the original pre-programmed plan, which is the definition of a non-agile environment. This is probably the most heard argument that is holding back traditionally ITIL-oriented IT organizations to move towards a more agile approach.

Framework vs. philosophy

Based on some of the points made above, agile approaches and ITIL are not exactly a match made in heaven at first sight, I think we can all agree on that. However, just like we say “opposites attract,” there are a lot of ways in which they actually can be used together very well. Agile is a philosophy, a set of guidelines for your work. For example, agile principles help you make decisions but they don’t tell you how to complete specific tasks. No roadmaps, just guidelines. ITIL is a framework, a collection of procedures that describe how to do your work in detail. ITIL does have a reputation for being rigid and unnecessarily complex, but ITIL was never meant to be a starting point. Also, ITIL is not meant to be fully implemented across an entire organization. ITIL is, has always been and always will be a very valuable set of best practices that is meant to be implemented in a way that works best for a specific organization. The way of implementing ITIL, or components of it, can very well be agile.