Me and my coworkers were seated at the table in our big co-working space. Employees from different sectors were brought together, ready to share their knowledge and skills with each other. It was 2014 and it was the first time we organised something alike. I just obtained my ITIL V3 certification and was preparing the training of 60 of my colleagues.
It happened that a young guy, who just finished his studies, gets the attention that he seeks. He believes he has something important to add to our meeting. His speech is rather absolute and he seems pretty convinced by himself and has a strong desire to criticise ITIL.
I hear him say: ‘It is absolutely necessary to eliminate the bureaucracy due to the implementation of ITIL in organisations. I am defending a Service Management design that is much more flexible and effective. My reference system is easy to apply and it can quickly replace ITIL. After all, ITIL costs too much and blocks organisations in heavy and unnecessary processes. All organisations that have implemented ITIL are regretting it nowadays because they would like to get out, but do not have the opportunity to do so”.
And here I am. I just invested a week of my time and was about to sign a purchase order of €40 000 to train a complete team on the ITIL best practices. Just imagine my concern! At the same time I realised that this was an opportunity to broaden my knowledge. I needed to know more.
So I decided to challenge the guy. Our conversation went as follows:
- “How are accidents resolved within your framework?”
- “Well there are almost no more incidents, so a return to Excel is more than enough”
- “Wow Ok.. So just for me to understand, is there an upstream contingency management approach? A proactive resolution to potential incidents based on observed events?”
- “Not even, the systems are stable by nature…”
- “Due to a specific set of technological choices?”
- “Yes of course, but above all thanks to a development method which removes any bug source…”
- “An Agile method”
- “Well yes, are there any other development methods?”
At this point I was triggered and thought “Let’s continue”!
- “So tell me, do you have any concrete examples of organisations that are locked with ITIL and like to leave? I would be very interested to understand their experience so that I can avoid making the same mistakes in my Service Management.
- “Like I said. All of them!”
At this point, I understood that I was dealing with a brilliant young guy that had lots of talent for argumentation and public speaking. However, no experience whatsoever with Service Management. I decided to end our discussion and postponed my interrogation to a later moment.
While we were all going back to our workplace, I went over to ask him the name of the magical Best Practice method we just discussed. He replied absently; “it is called DevOps’. This was my first contact with DevOps. The brilliant young guy had learned the DevOps lessons well, but had not yet captured its essence. So I decided to investigate the methodology independently. I found my path and I finally entered the world of Devops. But without ever leaving ITIL!
At that time, there was very little documentation on DevOps. Initially they were just good ideas that together formed a magma full of good intentions of which we could only feel the enormous potential.
In that same year, the first DevOps book was published. It is a book on IT and DevOps called ‘The Phoenix Project’. It tells the story of an organisation’s transformation through the radical change of its IT services. It is a book full of lessons, just reading it will provide you with experience on the topic.
It is true that at the beginning of the book some ITIL processes are criticised for their complexity. However it does not tell you to discard the practices completely. Going forward in the book, you realise the essential influence of Best Practices such as ITIL on the success of the DevOps transformation. Another key lesson is that while applying a Best Practice, it is important to eliminate everything that does not produce value. Doing this will provide you with a Lean-ITIL concept that covers part of the path towards DevOps.
Over time, DevOps has gained maturity, as have its users and experts. It is clearly indicated in the first pages of the Foundation training, that the three sources of inspiration for DevOps are ITIL, Lean and Agile. Just to make my point even stronger, ITIL’s obsolescence is considered to be one of the false myths about DevOps. I strongly believe that IT Service Management and the DevOps movement are not opposites. On the contrary, they offer a perfect cultural marriage (these are the words of Gene Kim, co-author of ‘The Phoenix Project’ and the ‘DevOps Handbook’).
This quote dates back to before the release of ITIL 4, which with its update has become more agile. If DevOps did not contain interest in ITIL V3, needless to say, it did not contain interest in ITIL 4.
Therefore it remains essential for IT services to acknowledge and apply ITIL practices in order to successfully use DevOps.
I often think about that young and brilliant guy. I can only thank him for initiating my DevOps journey. I don’t blame him for his carefree lightness… On the contrary, I wish him to have gained maturity at the same rate as the movement we represent together today.
If you are interested in learning more about DevOps? Read our blogs “What is ITIL” and “What is DevOps?” and continue your journey towards professional development!
