Nancy Louisnord
Nancy Louisnord
Nancy Louisnord is the Chief Marketing Officer at EasyVista, leveraging over 14 years of ITSM leadership to drive global marketing strategies and enhance customer service experiences.

ITIL 4 vs. Agile – A Growing Friendship

18 May, 2021

In the past, the question was ITIL vs Agile as the two seemed like opposing forces. Support teams seemed to embrace one over the other, or think it had to be either/or. Yet as IT service desks and teams are changing, forced to constantly pivot during the last year, many have found the benefits of utilizing both agile and ITIL.

If you’ve ever worked with ITIL in the past, you might be wondering how this is possible. But with the release of ITIL 4, agile became a methodology baked into the recipe for service management, so to speak. Let’s take a look at some of these changes and the ways to help ITIL and agile go from not-quite enemies to friends.

What is the Difference Between ITIL and Agile?

In their origins, agile and ITIL are nearly warring concepts. One is a structured framework while the other is a mindset encouraging adaptation and change.

What is ITIL

ITIL is defined as:

“A set of best-practice publications for IT service management. ITIL gives guidance on the provision of quality IT services and the processes, functions and other capabilities needed to support them.” 

ITIL also describes processes, procedures, tasks, and checklists which are not specific to any singular organization or technology. ITIL processes can be applied to knowledge management strategies and can be used with ITSM software.

What is Agile

On the opposite end of the spectrum, the agile methodology is a philosophy, more than a set of guidelines for your work. These principles don’t necessarily tell you how to complete specific tasks but help guide you in making decisions. Agile is a mindset that fosters flexibility and adaptability, which operates under the assumption that things can, and likely will, change and you must be ready and able to change.

This started in 2001 with the Agile Manifesto, which is comprised of the following four values:

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

This evolved into the 12 principles behind the agile manifesto. An excerpt of just a few of the 12 principles which apply well to service management include:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Businesspeople and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

ITIL vs Agile: Is ITIL a Contradiction to Agile ITSM?

We will dive deeper into the ways that agile and ITIL 4 work together in service management, but for now it’s important to understand that ITIL is not a contradiction to agile. ITIL provides a framework for processes, but the adaptability and flexibility mindset of agile can still apply. It doesn’t need to be one or the other.

For example, you can follow the ITIL processes of incident or problem management while still incorporating agile ways of thinking. This might mean including more points of contact for feedback, essentially to create feedback loops, or it might look like having a small team handle each problem rather than a larger more structured team. The team might still find it helpful to do the ITIL process, but work through it in a more agile way.

ITIL v3/2011 and Agile Service Management: A Look Back

Within ITIL v3/2011, you might have immediately noticed a clash in the values of the agile manifesto and ITIL processes. In the context of ITIL v3/2011, agile may have seemed like anarchy, with the guidelines of ITIL being thrown out the window.

Before the release of ITIL 4, I pointed out in an article for CIO.com that there were some significant differences in ITIL v3/2011 and agile. For example, ITIL attaches significance to everything that the agile mindset believes to be less important. At the same time, 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 qualitative services offered.

There’s also the fact that the ITIL v3/2011 methodology prefers comprehensive documentation – not to mention that ITIL v3/2011 guidelines fill five books with a total of 1,300 pages meant to explain the 26 ITILv3.

Even still, agile service management and ITIL could be done with ITIL v3/2011, it just takes a bit more creativity and flexibility.

Changes in ITIL 4 to Become More Agile

As service management shifted toward the agile methodology, ITIL followed the trend. ITIL 4 evolved to reflect the industry’s shift to agile practices and ways of working. The focus of ITIL 4 shifted to value delivery, making it a better companion to agile methodologies. Suddenly, it is no longer ITIL vs. agile but agile WITH ITIL.

Agile emphasizes shortening and strengthening feedback loops, and in ITIL 4 this is a key requirement in the Service Value System (SVS).

There are other similarities between the Agile Manifesto and the ITIL 4 Guiding Principles. For example, the Agile Manifesto includes “Customer collaboration over contract negotiation” and ITIL 4 now includes a guiding principle which states “Focus on value; Collaborate and promote visibility.”

The Agile Manifesto also includes “Responding to change over following a plan.” Anyone who has ever worked within ITIL’s framework for change management might see this as direct opposition, but with ITIL 4, a guiding principle includes “Progress iteratively with feedback; Keep it simple and practical.”

Furthermore, ITIL 4 did not just change the guiding principles, but the processes traditionally associated with ITIL.

For example: Change Management was renamed Change Enablement, and was redefined as the following: “To maximize the number of successful product and service changes by ensuring that risks are properly assessed, authorizing changes, and managing a change schedule.”

Moving from change management as a process to a practice put more of an emphasis on the idea of responding differently to changes of varying levels of complexity. At the same time, Change Enablement removes the focus on a Change Advisory Board (CAB) because they may introduce delays. In this way, Change Enablement opens the door to more agile ways of working, such as swarming and scrum teams.

Similarly, Incident Management in ITIL 4 now includes the concept of swarming and workarounds. In this way, there is already a focus on agile methodologies built directly into ITIL 4. You can read more about the specific changes, especially as it relates to incident and change management, in this blog post.

ITIL vs. Scrum – Can they Work Together?

The quick answer is that yes, ITIL, swarming, and scrum can all function together to create valuable outcomes. Scrum and swarming are two helpful parts of working in an agile way. Swarming and scrum are not completely separate but are two parts of an overall agile strategy. As a refresher:

  • Scrum is a cost-free framework for software development which makes it easier for organizations to maintain products and processes. In scrum, you learn by doing and your findings are the guiding light for the next step. Scrum has core values, including Courage, Focus, Commitment, Respect, and Openness. Scrum works best for small self-managing teams of three to nine people working within a step-by-step method. The team delivers a new or improved product or functionality, within a set period of time (two weeks, for example). These short “sprints” force you to constantly work with realistic deadlines.
  • Swarming removes hierarchy and enables a cross-functional structure and collaboration. It’s a simple way to boost the speed and velocity of the scrum team, and occurs when people come together from various departments together in a scrum team based on their skills to speed up velocity. In short, the team collectively tackles different aspects of the problem working as quickly as possible, thereby shortening the amount of downtime.

So how do these apply to ITIL 4? In ITIL 4, there is a greater emphasis on value co-creation, collaboration, and feedback. For example, in ITIL 4, incident management has natural periods of feedback, collaboration, and swarming. You can see more examples of ITIL and scrum in this context in our eBook, The Ultimate Guide to Agile ITSM.

How do you Get Started Integrating ITIL and Agile?

The simplest way to get started integrating ITIL and agile is through incident management. As previously mentioned, incident management has natural places to implement sprints or a scrum team and have natural feedback loops.

It’s important to note, however, that you don’t necessarily need to consider “implementing” or “integrating” agile and ITIL as much as you need to create a cultural shift toward agile thinking.

Agile is a mindset, and as such for your team to embrace agile concepts they must begin thinking agile. This means removing overly cumbersome processes that no longer serve a purpose or function for your team, but also remembering not to “throw the baby out with the bath water” so to speak and remove processes from ITIL that ARE working. This goes back to changing the way of thinking of ITIL vs agile, and instead thinking of which work best without limiting your team to one or the other.

To create a cultural change, you must shift thinking from processes to outcomes, giving people the opportunity to give feedback. That might mean giving employees the chance for more feedback or giving customers more input. You can also create a culture of agile by encouraging continual learning and growth. This doesn’t necessarily mean giving people courses to take but letting them step out of their comfort zone and try something new.

Using Agile Service Management for the Enterprise

Agile service management doesn’t need to be contained to only the service desk or greater IT department. Agile service management can function well as part of an Enterprise Service Management (ESM) strategy. Using cloud-based IT service management software to coordinate between departments, you can create an interdepartmental cultural shift to agile thinking

As an example, think of a Facilities department for a chain of stores who faces a variety of different ticket types and issues across a major enterprise. Some tickets might be for simple lightbulb replacements, while others might require several members of the maintenance staff to fix – like a broken appliance or problem with the point of sales system. Using agile ways of thinking, the facilities team can create scrum teams, so to speak, to solve the bigger problems. Meanwhile, they might find someone from IT is better suited to handle fixing the point of sales system. All the while, the customers (in this case, the store managers) can give feedback to make the process simpler in the future. This cross-departmental agility will help resolve the tickets faster.

In a similar way, you can implement ITIL processes in the enterprise beyond the IT department. For example, you can use the change enablement process in a variety of teams and departments to create a streamlined method of approaching something new. Together with agile thinking, ITIL can span across teams for a highly organized enterprise.

Agile is NOT Anarchy

I mentioned earlier in this post that agile is NOT anarchy, and I think it is worth mentioning on its own. Agile is a way of thinking that, when paired with ITIL, can help teams stay ahead of incidents and problems and help refine the feedback process. There is no need to think it must be “ITIL vs agile” when it can be both.

To learn more about the agile methodology and to understand its role in service management and ITIL, download our eBook, The Ultimate Guide to Agile ITSM.