ITIL Versus Agile: How IT Service Teams Can Avail the Best of Each Methodology

Agile and ITIL are two popular IT methodologies that have, at separate times, gained traction as a response to dissatisfaction with the “old way” of doing business. At a glance, they seem incompatible. ITIL methodology seeks to codify the processes and mindsets an IT organization should adopt to deliver consistent value in a repeatable fashion. Agile seeks to boldly innovate, ask questions, and shed fear of “breaking things” for the purpose of delivering value quickly in an evolving environment.

However, both methodologies have strengths that can compensate the other’s weaknesses, revealing a blueprint for IT organizations to bring maximum value to stakeholders without sacrificing the agility that is prized so much in today’s business world.

This post will illustrate opportunities for one methodology to learn from the other to provide value to teams, stakeholders, and customers.

Why Is Agile Methodology So Highly Prized in Modern Business?

Agile techniques intend to remove as many barriers as possible between ideas and their results. Unlike ITIL, which emphasizes a strict methodology for meeting explicitly-worded service-level agreements (SLAs), agile methodology encourages organizations to empower small teams to work autonomously and enthusiastically.

Teams are built from multi-disciplinary specialists, and they are expected to prioritize where their efforts are directed on a day-to-day basis. The expected outcome of these efforts is a visible result delivered fast. Teams work in “sprints” to produce an iterative prototype that helps them carve out parameters and provide a basis for setting further goals. Once an iteration is built, it can be improved upon through another series of sprints.

The basic four tenets are:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Agility is key in fast-paced environments, and this state of mind can be applied to ITIL to help IT service teams embrace change as it comes.

Why ITIL is Still Relevant in an Agile World

ITIL methodology came about in the late 1980s as digital technology worked its way deeper into the business environment. The original guidebooks offered a repeatable roadmap for IT Service Management (ITSM).

The benefit of ITIL is that everything is in writing. Teams know who they report to, what they are expected to address, and the process for implementing any changes, fixes, or improvements. Documentation makes it easy to audit changes or trace back to specific actions.

Such a rigid approach can face challenges in an agile environment, preventing teams from adapting or diverting from a planned course of action when needed. For example, ITIL-guided teams today must be able to predict and manage change risk on an ongoing basis.

“The permanency of ITIL processes can be too watertight,” Nancy Van Elsacker Louisnord writes in “CIO,” “leaving little way to deviate from the original pre-programmed plan, which is the definition of a non-agile environment.”

What ITIL methodology offers in exchange is predictability and accountability: SLA’s create a paper trail that codifies expectations and deliverables. But the system is not foolproof. Teams can deliver on an SLA and still leave users and stakeholders dissatisfied because the parameters listed may not have reflected the true business needs of these parties — or those needs may have changed.

In light of this challenge, some teams may find advantages in embracing an agile IT management approach while keeping the foundations of ITIL processes intact.

For example, teams can widen their perspective beyond the SLA to identify their true goals. Teams should include feedback from actual users, customers, and stakeholders in their reports, and use these responses to set priorities. They should also develop metrics that accurately reflect these sentiments. Seeking feedback from the actual users of technology ensures that IT teams aren’t blind to glaring issues just because those issues don’t happen to violate their SLA.

Another way ITIL-guided organizations can apply agile methodology is to craft one or more innovation teams and give them the autonomy they need to work outside the limited perspective of the SLA and the daily needs of the organization. These teams can run pilot programs with a small user test group or experiment with identifying unconsidered changes that can drive dramatic improvements in their organization — all of which create value for everyone involved.

Creating an internal “skunk works” team can solve nagging pain points, such as high IT incident volume. It can also open the door to new opportunities. The team that developed the business chat client now known as Slack originally just wanted to solve problems with the company’s internal communications. Because the team was permitted the resources to innovate, they ended up creating tools with a tremendous amount of value — both internally and externally.

Agile IT management seeks to eliminate much of the redundancy and micromanagement that is intrinsic to complex organizational structures. If teams are allowed to operate without constant reporting, supervision, and waiting for approval, those in leadership roles can, “Devote themselves more fully to higher-value work that only they can do: creating and adjusting the corporate vision; prioritizing strategic initiatives; simplifying and focusing work; assigning the right people to tasks; increasing cross-functional collaboration; and removing impediments to progress.”

Keeping ITIL’s Value Intact in an Agile Environment

Not every process can benefit from an agile approach. Work that is repetitive, predictable, and that takes place within a stable business environment may find agile IT management techniques to be disruptive. Additionally, some work has been performed countless times with clear solutions devised through organizational silos to the satisfaction of all, meaning that innovation invites unnecessary risk.

With these positive qualities of ITIL in mind, agile organizations should at the very least set down some ground rules for measuring success, handling crises, or meeting baseline expectations as a form of SLA. If that sounds too rigid, then the team can consider the document an “iteration” that can evolve in line with business needs.

Teams should also test and evaluate process changes to ensure that they don’t “break” things related to critical business functions. While the experimental scrum team can benefit from a lower pressure environment for developing prototype products or projects related to critical business functions, the final iteration should be a stable product thoroughly vetted and tested according to a repeatable process.

Agile teams must also understand their goals and who is accountable for achieving them. That way, there is a lower chance of the organizational chaos the first ITIL teams initially sought to avoid.

The major lesson to be learned when evaluating ITIL versus agile is that each methodology offers benefits that IT teams should be aware of and use according to the circumstances. An ITIL framework comes with best practices that are still relevant, and they can be adapted to agile methods.

Today’s business world is in a state of constant flux, as is the technology landscape that supports it. IT teams absolutely must keep pace with the latest technology and its corresponding demands. Not only that, but they must also keep up with newer ways of service thinking with business service management solutions. In today’s IT culture, any framework used should fit the agile purpose, not the other way around.