Agile and ITIL: A Powerful Combination
By Joe Pearson

I’ll admit I don’t think that agile methods can address all ITSM needs. For example, a high-volume Service Desk probably should not be run as a self-organising team that values individuals and interactions over processes and tools. Large parts of day-to-day service management are repeatable activities that need process standardisation – and the ITSM profession has been struggling to promote process control for decades. And there should be enough commonality in request handling and configuration management needs that in-house tool development is not the right option for most companies.

But everyone requires process development. You can’t just take the processes from the ITIL books and use them. And most commercial toolsets require substantial amounts of customisation for an effective implementation. In these areas, practices like frequent iterations and focused teams including users and specialists can surely have value.

There’s something worth investigating here, and I propose to examine principles and practices, see where they can be applicable, and what kind of coherent approach we can build.

Comparing Agile and ITSM Principles

• Just as software and database development build capabilities that support business processes, Agile Service Management is most applicable for the disciplines and teams building capabilities that support IT Service Management. That is, developing IT for IT rather than IT for business.

• Every environment, even the largest and best-planned, needs continual improvement; and many organisations can get greater value, and closer alignments to requirements, by implementing in smaller steps of proven value.

• Compared to Agile Software Development, ITSM development usually needs to develop or improve the IT processes much more than IT develops business processes (although there’s probably a useful debate to be had on that!). In fact, there’s more emphasis on process and less on developing software.

Agile Key Practices Offering Potential Value to ITSM

• Short, frequent iterations (of a few weeks), each delivering a self-contained (package of) requirements: Yes, this could help with budget control and management commitment – things that ITSM teams often struggle with. But the main reason I like the idea is to support alignment with customer requirements. A six-month project developing Service Operations processes and organisational change addresses the requirements as they were understood at the beginning of the six months. A set of one-month iterations, delivering functional operating processes and business value in each iteration, not only gets value to customers more quickly, it also makes it much more likely that the changes are what the users need and that emerging requirements can be swiftly handled – and it helps with user and management buy-in.

• Dedicated team including customer participation: Agile methods promote a team working together from beginning to end of an iteration, communicating face-to-face (including formal daily meetings), rather than separate teams communicating through formal requirements documents. I see the ‘customers’ of a service management development being primarily any IT staff, including those involved in day-to-day support (who would be users of a service desk tool, and an incident management process) and software developers (who would be users of a release and deployment process among other things). There’s a case for having the customers’ customers – ie the business end-users of IT – included as well. Having representatives of these customers in the dedicated team, continuously, would bring the same benefits as it does in Agile Software Development: aligning the delivered solution to real requirements, not to the shadow of requirements captured in some document, or the process developer’s (or tool vendor’s) assumptions as to those requirements.

• Refactoring: Instead of treating delivered ITSM processes as cast in stone, or difficult to update, teams should focus aggressively on optimising them. The philosophy of continual improvement embodied in ITIL practically demands this; Agile principles will enable it. Continuous attention to excellence and design matter. (I need to be careful about the terminology. Strictly, refactoring is changing code to make it cleaner and more maintainable without changing the functionality. When I think of refactoring an ITSM process it will of course change the job of the user (the IT staff member) – but without changing the business objective achieved.)

• Design patterns: I’d like to interpret ITIL as a set of design patterns: good reusable solutions to specific common problems. There is a vast amount of good material in ITIL, but not every organisation can benefit from every piece of it; a design pattern structure might help to clarify. With ITIL V2, we saw a lot of companies overlooking valuable guidance because they’d “done the basics” and were not clear on where a specific piece of guidance could help. A pattern interpretation could unlock this value. With ITIL V3, many companies are concerned that it’s too big or too complex to grasp. They are looking for modular, incremental ways of adopting best practice: presenting best practice as design patterns, stating what problem it solves (do we need this yet?) and what pre-conditions it has (are we ready for this?), is almost essential.

Closing thought

There are many different software development methodologies, on both the agile and the “waterfall” sides, all “best practice” and having passionate advocates. But there is only one ITIL. Why? Is ITSM simpler? Not much. Is ITSM less professionally and thoroughly addressed in most organisations? Is it because everyone does in fact develop ITSM with different approaches (all using ITIL as guidance) but it’s not treated seriously enough or understood well enough for us to promote different approaches?

Note: The article’s original title is “Agile Service Management”

Joe Pearson is a consultant specialising in IT Service Management (ITSM) and Business Service Management (BSM), with over 20 years’ experience in the UK and South Africa in organisations such as IBM, Dimension Data, Business Connexion and Foster-Melliar. He works mostly in the Gauteng province of South Africa (Johannesburg) and is a qualified in ITIL and ISO/IEC 20000. Joe can be reached through his blog, Deconstructing ITSM.