The Agile Manifesto

What IT Service Management can learn from the Agile Manifesto (and vice versa)

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.

Read the sentence on the bottom first.

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.

…don’t forget!  ABC is like an Iceberg…..a lot of it hidden beneath  the surface, and capable of inflicting damage!
…don’t forget! ABC is like an Iceberg…..a lot of it hidden beneath the surface, and capable of inflicting damage!

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.

 

4 Kommentare zu «What IT Service Management can learn from the Agile Manifesto (and vice versa)»

  1. Hi, Great article clear explanation and very easy to understand how agile manifesto can help it service management I agree with you that Agile has become incredibly relevant, also for the IT Service Management industry. it a great piece of knowledge.

  2. Pingback: Manifesto for Agile Service Management—Part I | This view of service management...

  3. Pingback: How to Implement Agile Incident Management - AITS Agile

  4. Charlie Volkstorf

    Agile development is simply doing what nontechnical managers want (early and frequent delivery, accepting and even encouraging multiple changes during testing, self-organizing groups) which makes it very difficult for technical people to optimize the final product.

    The procedure that minimizes the time needed for the first delivery is the procedure that maximizes the time for the final delivery. One big reason is that time spent on designing, and especially the development of tools, delays the initial delivery but greatly reduces the time per delivery. Nontechnical managers often lack the skills and experience to appreciate this. The overhead of making repeated changes (retesting, retraining, redocumenting), which can even include users going around in circles when there is insufficient analysis of the impact of a particular approach, is also not appreciated.

    As a result they say they favor “Working Software” over “Comprehensive Documentation”. The fact that they must choose between them shows they are producing undocumented systems because they make so many changes that keeping the documentation up to date is impossible. Also include in this untrained users and buggy software. The last change made is the least tested.

    They also say they favor “Responding to Change” over “Following a Plan”. Again, if they were more organized they would have a plan to follow that does not waste so much time making changes because they don’t have the time to fully consider what the best options for change really are. An ounce of prevention is worth a pound of cure.

Kommentar verfassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert