Agile has become incredibly relevant, also for the IT Service Management industry. This is nothing new. But do we really understand what this means? ITSM and Agile do not contradict each other. From my point of view two things are relevant: First, using agile project delivery methods and agile principles to drive ITSM initiatives forward (in contrast of using traditional waterfall methods). I call this CSI 2.0, because it finally brought the ITIL CSI approach down to earth. There are already many impressive success stories around. On the other hand, agile ITSM is about having a concept of integrating your ITSM processes and practices with agile service design & transition (e.g. scrum, crystal, dsdm etc.). As a side-note, the second one is also something DevOps tries to address.

The base for all modern agile methods is the Agile Manifesto, which has been around for a couple of years. It is a set of four simple value statements, originally coming out of the software world, expressing what works in practice and therefore constitutes value. Interesting enough, I believe ITIL actually supports most of these values and even brings in (agile manifesto) supporting elements which are missing in agile frameworks, but they are often overseen in practice. Why? Because they are not so easy to tackle and we (me included) always tend to stay in our comfort zone, which is rather talking about processes, KPI’s and contracts than tackling non-straight forward topics like customer collaboration and people, which are in fact more important for the success.

When now going through the four values, always keep in mind the following sentence, which is also part of the agile manifesto: “While there is value in the items on the right, we value the items on the left more”.

1. Individuals and interactions over processes and tools

Although processes and tools help to have an appropriate IT Service Management System in place, it is the people who design, build, run and continually improve IT Services. Adapted to ITSM, there are two aspects in this: First, the fact (according to studies) that 70% of ITSM projects fail. Why? Mainly due to the lack of addressing the so-called worst practices in the attitude, behavior and culture (ABC) of people. We talk here about stuff like resistance to change or no management commitment, which is very common and human. Nothing really new, but looking at the facts, identifying these worst practices and addressing them should be a cornerstone of every ITSM initiative.

Additionally, concepts which are mainly outlined in ITIL Service Transition can really help here: For example, the “Eight Steps for Transforming your organization” by J.P. Kotter. 50% of projects already fail in the first step because of the lack of creating a sense of urgency. Also don’t forget the importance of doing continuous stakeholder management: Knowing who your stakeholders are, what they want, what their importance is and finally getting them there where you want them to be. I spend a big proportion of my time in ITSM projects on this activity.

Secondly, looking at the agile manifesto, the actual service capabilities of the individuals should be a main focus point to be successful. Just an example: It’s not only about knowing how an incident management process works (which is anyway already industrialized, thanks to ITIL) and knowing the underlying goals of the process, but having the actual capability to solve incidents, which is very much about service and technical skills. This is often not paid enough attention.

2. Working software (or working service or product) over comprehensive documentation

At the end of the day it’s the IT Service which delivers the value to the customer. This of course heavily depends on good service strategy, design, transition and the ability to run the service (service operations). Although documentation is necessary and useful, it’s in most cases just something on the way to deliver value. Agile project methodologies consequently focus on value. They prevent “dead horses“. Prioritization is based on value (measured and planned through ROI, Net Present Value or Value Stream Mapping) and cut into small, doable pieces, which are implemented and immediately deliver value. In agile, it is never the documentation which is the end result, it is the (measurable) improved situation which you want to achieve, described as a formal user story. Just to give you a kind of brutal example: You might spend years to define your IT Service Management processes and also implement them, but you maybe didn’t address the most important customer painpoint that Changes are implemented without Request for Change, finally leading to incidents and instability in production. Alternatively, you might have solved that specific problem in one week by enforcing a Service Transition Policy and have this way delivered value by more stable IT Services. You can decide on your own, which approach (1 or 2) your customer will prefer…

In agile, value is delivered in an incremental and iterative way. In most cases it’s an illusion to believe that the customer already knows exactly from the beginning what his requirements are. You have to show him something early and adapts in the next iteration. Why not also adapting this to ITSM implementations?

As a side note: The original manifesto reads “Working software over comprehensive”. Software should be definitely replaced by Service, isn’t it?

3. Customer collaboration over contract negotiation

SLA fulfilled, customer unhappy. Sounds familiar? We all know about the importance of having SLA’s in place, out of that being able to set the right priorities, measuring Service Level Achievement and having this way an indication where to improve. There is no way around SLA’s and they are important, especially with external service providers. The problem: If you as a service provider only focus on technically achieving a SLA KPI’s (e.g. incident resolution), you forget what it is all about: Customer collaboration and Service attitude towards your customer. You can always try to put more KPI’s in an SLA to solve this, but there are many creative ways to achieve this KPI: If the Service Provider doesn’t have the right attitude and customer orientation, he will always try to cheat. This is the sad reality. It’s like a marriage contract: It will not make you a happy couple, but if things go terribly wrong, it’s definitely worth looking at it.

4. Responding to change over following a plan

In the current market, in which customer requirements, available technologies, and patterns of business keep changing, it is essential to approach service design and transition in an adaptive manner that enables change incorporation and fast product lifecycles rather than placing emphasis on following plans formed on potentially outdated data.

At the same time we try to achieve stability and planning reliability, which is against having to much change. So it’s a trade-off. If you increase flexibility, you loose potentially stability, and vice-versa. The big strength of agile methods is that they bring flexibility and stability in balance, they are able to achieve stability and flexibility at the same time on a high level.