I’ve been thinking…
- I am not a professional software developer or data architect, but I’m very interested in these disciplines through ITSM contact with practitioners and teams. (I often feel there’s a great loss of value in the lack of mutual familiarity between service management and development/data communities.) One of the approaches I have been particularly interested over the past year or so is Agile Software Development, the Agile philosophy – see the Agile Manifesto, and some of the key practices associated with Agile development like test-driven development, refactoring and design patterns.
- I observe that many ITSM projects (“implementations” or improvements) suffer from issues with long timescales, inability to cope with changing requirements, lack of user acceptance, and so on. Not all, but those that do suffer tend to be blind to the causes and show resigned acceptance to such issues – or even to be blind to these issues.
Those issues, and others I haven’t listed, are very like the kind of things the authors of the Agile Manifesto were experiencing. Agile development is very successful in certain environments (though not all – and more traditional “big requirements up front”, “big design up front” methods have strong defenders). Could Agile principles be applied usefully to IT Service Management problems?
Agile Service Management
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.
Just as software and database development build capabilities that support business processes, I think Agile Service Management will be 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.
Secondly, I’ll focus on modular self-contained improvements rather than building the entire ITSM capability. There is a need for architecture, massive engineering and “big design up front” in large-scale ITSM systems. (Some of the best thinking on this issue can be found at Charles T. Betz’s blog erp4it.) But 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. It’s the other end of the scale.
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. These topics need to be explored more, though.
In future posts I need to look at the Agile Manifesto principles, and other Agile practices, but for now I just want to touch on the key practices that I think offer potential value.
- 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.
More to follow.
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?