If you want a one-line summary of the challenge faced by people delivering IT services, you could do worse than “How to deliver more and break less”.
Given that there isn't a limitless pile of money available to throw at this problem, and that there are constant pressures to reduce costs, clearly we need to improve our practice if we are going to reduce the breakages.
The good news is that there is room for improvement. Despite years when change and release management have been viewed as core ITIL processes, likely to get an organisation’s attention before many others, we still haven’t got these essential elements cracked. Much is spoken about agile and DevOps, but when push comes to shove, many people are still taking a more ‘traditional’ approach to release management, if they have got that far.
At a recent Service Transition SIG meeting, we took a look at the sort of challenges that face us in deciding how to do release management, and a range of approaches we can use in addressing them.
We started with our hosts Arqiva, who outlined to us the complexities that they face as they serve customers with competing demands. They have to balance their requirements on a shared infrastructure. And if they mess up, they are acutely aware that the nation will know, as their mistakes have the power to bring down television or radio transmission. Arqiva explained how they have delivered impressive increases in the reliability of change implementation, but still face some challenges in release management.
So what sort of models could be applied? There isn't a ‘one size fits all’ here. Some organisations, we discovered at the meeting, focus their release management more at the technical level, while others opt for an implementation scheduling approach. Others might want more of an enterprise overview, coordinating the dependencies which projects look after. We looked at the challenges faced in each case and the potential role conflicts inherent to each approach.
We then considered how to bundle releases, whether going for the ‘small and often’ or the ‘big and occasional’ approach (or a mixture). We considered the possible constraints in both cases and what kind of a release plan you might put in place to help alleviate these limitations.
Smaller and faster projects tend to be linked with agile, but this isn't necessarily the case. Those using the traditional ‘waterfall’ approach can learn from agile here. On the other hand, if attempts to be more agile are too eager, there is a danger of relaxing the waterfall controls without recognising that agile has controls too. Basically there isn't a shortcut. If you want to improve you have to work at it.
Planning is an important area. We considered the factors that can torpedo what might look like a good plan, complete with plenty of contingency, as projects still end up getting put back and put back, with huge overruns resulting.
So, now we have set ourselves up to deliver more. Great... but only if it works. How do we reduce the fallout? Approaches to testing are key. A measured approach comes in handy here. Things don't always work first time so why do we assume they will? We want a well thought through approach to testing, including awareness of the risk/opportunity equation, so that we are not just doing endless testing for the sake of being bullet proof, but delivering too late to be of any use.
If we understand the importance of good testing we will prepare our scenarios in advance, consider where automation can help (bearing in mind the pay-back period) and, where we are not automating, assign people to perform testing who have both the right skills and the will to do it. And it would be really helpful if we could ensure our environments match as well, so that we are testing like for like and can see the wood for the trees.
If you would like to find out more about the Service Transition SIG’s work on release management, why not attend one of their regular events which you can find on our event calendar.
ITSMF UK also run a series of workshops and masterclasses covering many topics including Release Management.
This article first appeared in the Spring 2015 issue of Service Talk