Agile Incident Management

In the last few months I’ve done a lot of reading about Agile. Not about Scrum, but about what the hearth of Agile is, what it means to say, “we are agile”. The reason for all the effort is that as an ITSM consultant I always try to stay up-to-date and improve my “adopt” skills. As we all know in the end it all comes down to adapting a framework and adopting it to your needs.  The framework is clear, as I am an ITIL Expert and there lies my expertise. Can this framework, which many see as old-school and thing of the past, be implemented in a new and modern way?

The answer is clearly YES!

We all know the Agile Manifesto and the four key points:

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

Now, if you don’t want to quote and try to explain it to friends or family, would you say that being agile means that you want to be flexible, but at the same time deliver predictable results, with regard to volume and speed of delivery? The key word here is predictable, meaning that you know it and the customer knows it well in advance. So, if both sides are ok and you shorten the delivery cycles, you will be able to get quick feedback and thus improve the overall quality. Key words here are feedback and quality.

Sounds great and this is why more and more companies are doing their business in an agile way. How about those IT Service Management oriented companies, where support plays a major part of their business and they have implemented ITIL years ago? The answer for me is still YES!

To prove my point, I will take the most popular ITIL process: Incident Management. As we all know this process is about restoring the service to normal operation as quickly as possible. It is about time, there are Service Level Targets, like Time to respond, Time to resolve, etc. The process is hard, because it is related to pain. A pain that the customer has and asks us to remove as quickly as possible. After working with many different customers and reading the beloved ITIL volumes, I can now honestly say, this is not the full truth. The customer not only wants the service back, but if possible, he wants it in a more predictable way, with the possibility to share feedback on the way, both positive and negative and in the end, get the quality he is paying for. Does this remind you of something you just read?

The broken printer showdown

Imagine the classical situation, where you want to print some critical paperwork, you are in a hurry, the deadline is today and… the printer is not working. You call the hotline, they ask you about the IP address of the printer and say “bye”. You stay there, alone with the not-working printer, hoping your colleagues will do some magic. Time passes, you call again, they say they are working on it, but not committing to any deadline. The resolution target is 8 hours, so, please don’t yell on the phone. Finally, in the last moment you get it printed and the day is saved, but you are full of mixed feelings about your company processes and your colleagues’ work.

TwinLooperChorzow

Agile Incident Management

The idea came to me on a Lean oriented workshop, when discussing the so called “5 Whys technique”. Do you know it? If not, it is basically repeatedly asking the question “Why”, until you find the reason why things happen the way they happen. Classical Problem Management technique in ITIL as well.

Anyway, imagine now the same scenario with the printer. How about changing the question to “How”, instead of “Why”. How can we restore the service? Can you identify a first answer and go for it? Can you share this goal with the requestor, so that he is aware of what is to come? Can you also give him a predefined timeline, how much time this attempt will take and when he will receive feedback about whether it was successful or not? If the answer is yes, we are in the agile business, are we not?

My guess is that for 100 incidents you will not need this every time, but let’s say for 10-20. Still, for the ones you do, you will deliver predictable results with customer feedback on the way and achieve the best possible quality.

Is this change too big?

No, you will just need to change your culture a bit. Allow for more collaboration with the requestor. Don’t forget that the requestor is in pain. Try to keep him in the loop of what is happening, so that he can deliver feedback on the way. The most important point here is that we are selling services, not processes. And selling services is about making this extra effort, which might look as too much, but in the end, assures we have satisfied customers.

 

Did I mention DevOps?

As written before, I believe that Agile ITSM and DevOps can go hand in hand. The first will provide the goals and govern the service delivery, where the second will help you out in the implementation phase of these goals.

The main purpose of this article was to show you that being agile is not the same as developing software with Scrum sprints. Being agile is a mindset, an approach to how we deliver services and run our processes. It can be applied to ITIL processes, so that we increase the value to our customers.

 

 

nikola

Nikola Gaydarov

Director IT Service and Project Management

Nikola has been in the IT sector for almost 10 years. He started his career in HP Global Delivery Center back in 2007 and since then has been involved in many different roles: technical consultant, operational manager, transition manager and ITSM implementation consultant. During these years he has worked both domestically and in Western Europe.





Author: Nikola Gaydarov
Nikola has been in the IT sector for almost 10 years. He started his career in HP Global Delivery Center back in 2007 and since then has been involved in many different roles: technical consultant, operational manager, transition manager and ITSM implementation consultant. During these years he has worked both domestically and in Western Europe.