“We are not allowed to mention ITIL or SOA. Our CIO is fed up with it”
ITIL implementations fail, not because they are done wrong or that there’s something wrong with ITIL but simply because it is not appropriate to blindly implement ITIL as an off the shelf solution. The specific needs of an organisation must be taken into account and ITIL adjusted accordingly. ITIL is a set of best practices derived from a wide array of companies and industries. It’s a toolbox that can be deployed to improve your IT service management – not something tailored for any specific organisation or a one size fits all solution. Yet many companies have tried to implement ITIL. They force an entire library of processes and policies onto their organisations. These companies often end up with bureaucratic monsters that achieve none of the planned benefits. From a development perspective, the perception is that IT service management equals bureaucracy and overhead.
“We try to avoid involving IT operations in the deployment process since that would negatively impact time to market”
Although IT service management frameworks like ITIL include collaboration, process improvement, cultural change and empowerment, these are not the parts that are normally emphasised during an ITIL project. The reason might just be that working with these parts of change management in projects is the hard part. Instead, the effect is bureaucracy and overhead – or just loads of fancy documentation but no actual change.
Due to failed and overly bureaucratic ‘implementations’ – control and governance is being challenged. Companies need agility and there is an abundance of methodologies and approaches to choose from such as Scrum, Kanban and DevOps. But with them comes the same risk of failing yet again. They are not one size fits all solutions either. More often, development teams end up with a carte blanche to do as they please, whenever they please. From an operations perspective, the perception is that agile equals anarchy and chaos.
”Since we started with scrum, we have no control over our deployment process. The developers are just putting new code in production all day long”
Agile methodologies require discipline and processes, some even more than the most robust IT service management framework. However, these are not parts that are emphasised. The reason might just be that these are the boring parts. And the effect is chaos and anarchy.
At 3gamma, we are witnessing first hand the friction that arises between development and operations in the interface between ITIL and agile methodologies. Fundamentalists on each side are blaming each other. There is no common ground.
We believe that agility is a key part in the delivery of IT services within any organisation. Agile principles can be used as a tool to bridge the perceived gap between development and operations, not through a one size fits all solution, but by carefully applying agile principles to the delivery organisation. Examples include:
- Improving performance by applying the idea of self-organising teams to the IT service management organisation. A common pitfall is to create process silos with isolated experts in each process. The idea behind the self-organising team is that the people closest to the problems have the deepest knowledge of how to solve the issues.
- Improving throughput and performance by creating focus through reduction of the amount of work in progress. At any given time, in any IT service management organisation, chances are that the amount of work in progress is alarmingly high. The effect is often that throughput drops considerably.
Self-organisation and focus are two examples of principles that can be applied to close the perceived gap between agile and ITIL. The application of these principles is not contradictory to anything stated in an IT service management framework such as ITIL. As noted above, these frameworks contain guidance on cultural change, collaboration between development and operations and continuous process improvement. However, due to the way the IT service management frameworks have been interpreted and implemented, they are perceived to be the opposite of agile. In fact, they are not!