Six Tactics for ITSM to Deal with Agile

As far as mainstream ITSM is concerned the primary impact of Agile development method is on our carefully constructed production environment. Agile has the potential to undo decades of work building protection for the assets for which we are accountable. It's our job to control risk as well as enable value. Sometimes it seems Agile ignores the former in pursuit of the latter. Here are six tactics to help deal with that.

In a recent online chat* with Dave van Herpen and Rod Weir, Dave asked about how ITSM should deal with Agile. I suggested six tactics:

1) Ring-fence the Agile production target

Some business unit has adopted Agile methods (usually Marketing or Communications or HR) over the protests of IT Operations? Fine. If they want to adopt an elevated risk profile that is their decision. But it is your job to maintain the risk profile of the corporate data and applications until instructed otherwise by the governors.

So try to limit the damage by separating out - ring-fencing - their production target.

• Any data it updates should belong to their system, not be a shared resource of the organisation
• Any code they modify should belong to their system, not be a shared resource of the organisation
• Put them outside your security perimeter, or at least partitioned off
• All interfaces to corporate data or systems should be via the same interfaces used by any external agency, and treated the same way

Give them their own little world to play in - and screw up - at their discretion.

2) Get a waiver

And if you can't achieve tactic #1, then get a written waiver signed by the business owner of the group wanting Agile, which agrees that you have explained the elevated risk to the corporate assets from rapid repeated change with reduced controls, and that business unit accepts all responsibility for loss or damage caused beyond their system.

3)Governance

Any team adopting Agile methods is asking for an elevated risk profile. This ought to be an informed business decision taken at the highest levels as a matter of policy, but almost always isn't.

Sometime I'll blog more broadly about the modern taste for increased risk in the name of agility or efficiency. I'd have thought recent economic events put paid to that but apparently not. You can get away with higher risk but only for so long. Repeated risk taking (say for example in high-frequency Agile releases) is only asking for probability to have its way. You can get away with it but not for ever. Everyone in IT should watch Aircrash Investigation as a job requirement. I had this conversation recently: I'm happy to visit Manila, but I'd be mad to live there for years on end.

So do what you can to escalate the issue of Agile risk to the governance levels of the organisation, with as much accompanying advice as possible so that governors or senior management can make an informed decision. If the decision is to adopt the higher risk profile, then our job is to manage that risk as best we can. We don't need to obstruct - we can collaborate within an organisational decision to go for it. that is the basis of the following tactics:

4) Give them standard change

All organisations that have change control should have standard change. if you don't have standard changes and you face complaints and resistance over change processes, it serves you right. I tell all my clients standard change is mandatory from day one in order to facilitate cultural acceptance of any new change management regime.

If you don't have standard change and Agile is coming and you can't ring-fence it, you have a major problem. If you do have standard change, then you only have a serious problem :) Work with the Agile implementers to find as many procedures as possible that can be categorised as standard change. This is of course an ongoing process: after they've hurled a few releases out there, you can start assessing the procedure for eligibility as a standard change. And then you can work with them to adapt their procedures to meet eligibility.

This isn't the place for a lesson in standard change, but in a nutshell a standard change is a type of change that is pre-approved. They still need to record the change but they don't need to seek permission every time they do it, just once in advance for all future occurrences of that type. The key elements (for me) are:

• Standard change types should be assessed on risk not scale of change. Big change can be standardised if it is low risk, and small changes aren't automatically standard ones until proven to be low risk
• Repeatability
• Fully documented and tested, especially including back-out/recovery procedure: this is the "standard" bit.
• Most of all: unambiguously defined. Before you open the standard change door, it has to be agreed and clear what constitutes that type of change... and what doesn't.

5) Automation

Automation of Agile change is a large chunk of what DevOps is about, as I understand it (along with some hippy-dippy stuff about how we can all be one happy family without specialisation or tribal divisions). Yes DevOps helps minimise the risk of Agile change, but it is not a silver bullet. It doesn't circumvent the need for the previous three tactics - it only reduces the risk somewhat. Three issues:

1. Automation doesn't prevent errors, it just changes their type from many small ones to fewer more catastrophic ones.
2. Automation is often inappropriate . Automation is expensive. We in IT always underestimate the TCO of automating our own processes.
3. GIGO. Automation is just a tool. No tool fixes process, practices, roles or attitudes.

6) Outreach: have an Operational Readiness programme

I've talked a lot about Dead Cat Syndrome, and the need for an Operational Readiness practice that bridges the gap between development and operations/production. A key principle of that practice is that the ultimate accountability is with the owners of production, and so it is Operations' job to seek out developers and talk to them not vice versa. Operations should have an outreach programme which offers advice, guidance and tools to help projects get systems operationally ready, baked in from day one of the project.

Project teams - including Agile teams - should know what they are in for and what is required to get stuff live long before the day comes.

As always, I'm no expert on this stuff. These six tactics are suggestions which will hopefully stimulate some healthy debate. Over to you...


* It was a "Tipu Talk", wide ranging ITSM chat loosely related to my Tipu improvement method. I've since dropped the Tipu Talks but may soon revive them as "IT SkepTalk". Let me know if you'd like to see that.