There have been many attempts by thought leaders to link ITIL and Agile methodologies, be it SCRUM, XP or other ones.
Some say Agile and ITIL complement each other, some others opine that ITIL can be modeled in Agile. Some other organizations delving newly into agile for development projects are spawning a different thread how agile can be incorporated to reap accelerated benefits in Managed services activity (the terminology used for IT service management) without understanding the nuances and nitty-gritty of either of these. For the sake of this discussion, I will limit to SCRUM Agile methodologies that being the most popular one and benefits achieved through SCRUM related ceremonies are easily perceptible.
From my experience of delivering both Managed Services Operations and Agile based development projects, I ,convincingly, say that ITIL service management processes already follow all the basic tenets on which Agile methodologies are espoused and advocated on. To my conviction, IT Service Management-Managed Services Engagements in the ITIL model is inherently agile and that should be left to run as it is without complicating it any further.
If one digs deep, ITIL basically classifies the followings:
- Incident management
- Service Requests
- Problem Solving
- KEDB – Known Error Data Base
- Configuration repository.
Incidents or Tickets are reported by business users which can be compared with stories in Agile. The level of incident reporting is at a very granular level of developer comprehensibility and hence qualifies the readiness criteria of a story and task. The same user plays the role of Product owner for giving additional inputs and certifying the solution at the end.
Incidents are prioritized which exactly the same what is done during backlog is grooming. Service Requests and Problems also follow the path of prioritization with a different cycle – Sprint cycles with different durations.
Logical segregation of Teams is based as per functional area and none of the teams are bigger than 8-10 people team. I have implemented daily stand-up within the team in a managed services operation resulting into benefit of collaboration and faster impediment resolution and the result was explicably beneficial.
When a particular incident or Service request is fixed after UAT (User Acceptance testing – can be logically same as demo feedback) and moved to production system, business value is delivered to business users or to product owner and that happens in a comparative short cycle.
While RCA (Root Cause analysis) discussion can be nearly related to sprint retrospection, there can be a periodic visit and look-in amongst team members to chew upon what are going well and what needs to be discarded at a regular interval of 2-3 weeks. This generally happen in some form or other already in any kind of engagement.
It is very clear from the above discussion that traditional IT support service engine runs like any other well-oiled machinery with improvement of efficiency and productivity on a regular basis – the concept of velocity and improvement on the same is also mapped in this case.
Known error Database and the knowledge repository is part and parcel of any execution engine and hence do not warrant any special mention in this discourse.
If one thinks a little into philosophy of both these approaches, the seed they stem from is providing business value at a shorter period and hence similar in nature of execution – this is no rocket science.
With this I conclude this discussion.
Will you share your thoughts?