Don’t do #ITIL, except this!

As most frameworks, especially with a business case for selling trainings and/or certifications, ITIL and/or iTSM is way too complicated and massive to implement in organisations. It’s not practical anymore. So don’t do it. 


There is (at least) one thing #Agile organisations can learn from iITIL/iTSM and that the difference between incidents and problems or, even better, the difference between an incident and a problem mindset for your team. 

🚨 Incident

Something’s broken. Your application/service is down or not functioning properly. Your users cannot use it (or are very limited).It’s hurting your reputation and business. 💩. Your number 1 priority is the restore the service to it’s normal way or working. With any means necessary. Here (digital) ducktape and WD40 come in. In most cases, a role-back of the change you just implemented, is needed. Or you need to temporarily patch things up (bandages). More often than not, it means your are fixing the consequences of the incident instead of the root cause and that’s fine. Primary goal is: Services/application up! And not per se, solve the (root) cause.

Services up again? Crisis gone? 😮‍💨Breath…

Now go into problem management mode. Relax, there’s time, incident is gone. 

🤔 Problem

Two things are important in problem mode:

  1. Find the root cause to the incident (if not found already). That means solving the underlying issue and removing the temporary bandages.
  2. Prevention. The most important question is: What can we do to prevent this from happening in the future? And then implement them!

🪦Isn’t that a post-mortem?

I know this sounds a lot like a post-mortem, and for most part it is. And you can definitely use the post-mortem meeting to get things going. The difference is that a problem is solved in ITIL only when the actions are implemented and they have the results you were looking for. It is a mindset that people seem to forget when doing post-mortems (usually the ideas in a post-mortem are forgotten the moment the session ends).

By the way, this works for any kind of incident/problem! HR, Marketing, Sales, team dynamics, etc. and so on…, not just in your product organisation.