I hear a lot of conflicting and contradictory statements about how the principles of Agile and continuous delivery – which focus on agility and velocity of changes/releases, are in opposition to ITIL principles, which espouse a more formalized and controlled structure to changes. Having responsiveness and velocity is good but not at the cost of control, for, when there is no control, chaos and anarchy set in, which is what any good practice framework aims to eradicate rather than support.
Agile in no way proposes that we do shoddy work with releases and work products just to get them over the line in order to achieve velocity. I think there is a lot that can be achieved by borrowing principles of Agile into ITIL® implementation projects. There’s a great amount of synergy between Agile and ITIL® which can be exploited.
Understanding Agile and ITIL®
Agile draws its strength from breaking down huge ‘monuments’ into bite sized chunks and prioritization of those chunks into something that can be readily worked upon and delivered. The beauty of this approach is that the delivery of the chunks has to be time-boxed. Every iteration is intended at delivering a meaningful and working work product. The soul of agile can be found in the agile manifesto which values:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
At first glance, these might appear to be in stark opposition to what ITIL® proposes, I will revisit these agile principles at a later point in my article and try to dispel the popular notion that ITIL® and Agile can’t coexist, for starters, let me just say, they very well can.
ITIL® is a best practice framework which focuses on a *service* paradigm i.e. providing value to customers (in the form of services delivered) and helping them achieve their desired outcomes, ITIL® aims at continual improvement of the various service lifecycle stages from service strategy, service design, service transition, service operation and continual service improvement.
Debunking the theory
With the groundwork in place, let me know try and drive home the point how Agile and ITIL® can complement each other.
1). Individuals and interactions over Processes and tools
A process is nothing but a structured and organized way of doing things, a process may be very well documented but at the end of the day its success or failure depends on the people who perform the process activities, many ITSM process implementations fail just because process and tools gain precedence over people and it is believed that getting the process and tools in place will cure all the ills but it seldom happens.Getting the people to understand and support the processes is very important. Communication and involvement of stakeholders can’t be emphasized more than during a process implementation. Stakeholder management becomes paramount here. The most commonly used quote in ITSM parlance comes to my mind “A fool with a tool is still a fool”.
2). Working software over Comprehensive documentation
Though this comes from a software development backdrop, translating this for the ITSM world would mean that instead of making a voluminous process document and handing it over for others to follow all at once, we should try to implement small but visible changes.
For example if in a set up where there are too many incidents caused due to changes, the most rational thing to do would be to first initiate a mechanism to let no change go into production without being tested prior to deployment,this will improve the change quality immediately and will fix the major pain point. We can, later on, of course go on to write a formal process document with all good looking visio diagrams and flowcharts. We must target the ‘quick wins’ to show value and then focus on the bigger more complex things.
3). Customer collaboration over Contract Negotiation
This essentially means that ITSM practitioners can derive a great amount of value by focusing on customer collaboration rather than just following a contract with SLA numbers and just striving to achieve those numbers, we have all been in situations where SLA targets are met month on month but the customer is still not happy with the service provided, showing all the care and concern for the customer at the time of contract renewal serves no purpose if we make no efforts to understand concerns, changes required, new requirements and gather feedback from time to time.
4). Responding to change over Following a plan
Traditional process implementation projects draw out grand plans and detail everything in the Gantt charts, sometimes because of the involvement of so many variables, all this becomes so complex that if any change is to be made to the plan, the effort required to do so becomes huge and hence there is little acceptance to change. It makes a great case to make small plans to be able to be flexible and nimble enough to make changes whenever the need arises.
The holy alliance
I see no reason why Process implementation projects can’t be broken into smaller manageable chunks, For example for a service catalog assignment, the smallest possible start that can be made is by defining all services and taking the list to business, understanding from the stakeholders if something needs to added/repealed, other details can be added subsequently in the next iteration. Coming up first with a static service catalog is like winning half the battle, the initiative can be matured over time where a dynamic and actionable catalog would be at the highest level of maturity.
I also see great value in holding daily scrum meetings in Infrastructure support projects. If a business is such that it sends out 5 releases in a day, there is no harm in holding a daily CAB meeting to ensure checkpoints are adhered to. ITIL® doesn’t say you can ONLY have weekly CAB meetings, ITIL® just says there should be a body like CAB and very rightly so,to monitor and control what changes are made and how they are made, how it is done in an Agile environment depends on the acumen and inventiveness of the process architect to adapt and adopt.
There is the element of Continual Improvement in Agile which tries to shorten the release cycle with every iteration, the CSI publication of ITIL® has a very strong focus on improving all lifecycle stages through the feedback loop, another value etched strongly in both frameworks.
Agile ITSM as a concept has been in existence for sometime now and it is an idea whose time has come. Needless to say, the more and more we ITSM practitioners realize this, the better it would be for us and we would see lesser ITIL® implementations failing because they became too big and unmanageable,if I am not wrong, one study showed 70% of ITIL® implementations fail, the time has come for us to change this.