Change management aims to ensure that standardised methods and procedures are used for efficient handling of all changes. A change is an event that results in a new status of one or more configuration items (CIs), and which is approved by management, is cost-effective, enhances business process changes (fixes) – all with a minimum risk to IT infrastructure.

The above description of change does not include fast. It talks about cost-effective and minimum risk, which both implies a bit of slowness. So one of the questions the business have to answer is their prioritization. Fast, with a higher risk or slower with a less risk. If you want both, you need probably need to do major changes to your IT infrastructure, neither cheap or risk free.

Think of a road with lots of crossings. If you drive real fast, the the risk is much higher than if you drive slower. What you could do is to rebuild the road to a motorway and take away the crossings to minimize the risk of collisions. Another mean is to reduce the damages if somethings happens. Safety belts and airbags does not avoid accidents, the tries to make the impact as minimal as possible. A third alternative is to have systems in the car that helps the driver to avoid a crash.

Back to ITIL, the CAB is more like a traffic light who stops all traffic and causes traffic jams in rush hours. In the best of worlds, it works as a roundabout and only slows down the traffic, not halt it.

There are number of parameters to resolve in order to improve speed for changes.

Size and complexity of the change. If the change is large and have implications for a large number of systems, then the change is more risky. It takes time to resolve the consequences of the change and the uncertainty is higher for a large change than a small change.
If the same change is done more often the there is less chance of something going wrong
If we test more, then the risk of something going wrong get less. But, more testing need more resources and thus more cost, unless the tests are automated.

Is agile software development in opposite of this?

If you develop bi-weekly sprints and implement changes every second week in production, the changes are smaller. If you the have test-driven development, the risk of faulty code causing major problems is rather low. This complies very well with Standard Change Model in ITIL that is used for repetitive, low-risk and well-tested changes.

This is what happens to a lot of apps in the mobile world today. When were there a CAB decision for a new update of your favorite app.

The challenge with agile development is when you need to to large changes that doesn´t fit into a two week sprint and release to production cycle. This is not an ITIL problem, this is an architecture problem.

To be continued in a second article next week about the cost and benefits perspective of changes.

Disruptive architecture