With the increasing prominence of both Agile and IT Service Management in current IT-related discourse, it's inevitable that some will ask "why not Agile ITSM"? Surely, those stick in the mud ITSM types with their Change and Release processes (so often impediments to developers) could use a little agility!
I've no doubt that some digital ink will be spilled in well meaning attempts to square this particular circle. But while there is plenty of room for continuous process improvement and Lean techniques applied to ITSM, applying the specific set of practices termed "Agile" (in the context of software development and project management) I think is misguided.
In order to make this case, I am going to refer to my industrial analogy for IT, that software development is product development. In both areas we find creative, risky, iterative, and non-deterministic processes. Agile might well find applicability in manufacturing R & D labs (at a guess, they already are doing similar things).
Agile makes a great deal of sense in terms of building novel symbolic structures (software) to meet emergent information needs. The need tends to co-evolve with the solution so an iterative approach is required. But these elegant and effective structures require much sweat of the brow. Even once a compelling presentation and experience is envisioned through well-applied Agile practices, there may remain tough ground work in creating a robust implementation.
How is this different from manufacturing, where a beautiful prototype may still require substantial investment in order to "tool up" a workable manufacturing line? And once that line is built, it will have degrees of freedom along which the product might change - and constrained dimensions along which change is impossible without re-engineering.
And once you build the assembly line - or the transactional system - you need to run it with a high degree of reliability if it is to merit the label "service," which implies simultaneous production and consumption. Complex systems are prone to emergent chaotic dynamics, and change is the enemy (whether labeled "Agile" or not). That is invariant in any systems engineering, with theoretical foundation in Turing's proof of the insolubility of the Halting Problem along with much other math & science. Test-first development, while an excellent practice, does not solve the Halting Problem. You cannot test all paths, and the more extensive the testing harness, the more invested in it, the less the agility. Re-factoring, while another excellent practice, cannot be construed as risk-free. Any new execution path has increased probability of failure. And no reliability, no service, no Agile ITSM.
So, instead of attempting "Agile ITSM," why don't we accept them each as two poles of dynamic tension? There are some areas where rapprochement may be possible - e.g., do "Design for Manufacturing" practices have any applicability? Certainly, the philosophy of high cohesion & loose coupling is beneficial from both an Agile and an ITSM perspective.
But, to borrow from the Hindu Trimurti, Brahma the Creator and Vishnu the Preserver are fundamentally different aspects, and in the case of large scale IT need to maintain some distance in order to ward off the untimely appearance of Shiva the Destroyer.
CODA:
I am remodeling my house, and have replaced pretty much all the mechanical systems. I was confronted with a classic example of interacting systems dynamics yesterday morning. We've purchased and had installed a high efficiency boiler and "sidearm" water heater, a very nice, cutting edge system. (See my interview with Billy the boiler geek, with reference to 10Base2 networking).
By definition, "high efficiency" means that the heat is going more where we want it, i.e. into the heating pipes. It is going less where we don't want it, i.e. as "waste" heat given off by the boiler unit itself. But in the old system, that "waste" heat was just enough to maintain an ambient basement temperature just above freezing...
So, yesterday morning, we awoke to a waterless house. The basement had gotten cold enough that the water service had frozen at the point of premise entry. (Fortunately, it did not burst!) After some panic, we applied a hair dryer and all was well.
But there I had, in the small, a perfect example of the chaotic interplay of systems. The plumber did not foresee it. The boiler guy did not foresee it. The excavator (who dug a 4' trench below the frost line and installed the shiny new copper line to the city water main) did not foresee it. The general contractor did not foresee it. It was outside of everyone's experience. And yet it happened...
