At the end of the second world war, the inhabitants of several pacific islands thought that if they emulated the behaviours of the colonists and forces personnel they had been observing and interacting with, they […]
Service Transition advice, guides, thoughts
Category: process
Knowledge Management: the Importance of Closed Loop Feedback
In business, data is always an asset. Information is an essential. Knowledge and wisdom are the key outputs of both. As a business grows, it should harvest good quality data and information that form shared […]
The real problem with frequent emergency changes
Changes are decisions, balancing risk and reward. In the language of Decision Theory, they are classed as normative or prescriptive decisions (i.e. identifying the best decision to take) which rely on access to good information […]
DevOps and ITIL: Continuous Delivery doesn’t stop at software
DevOps. The next saviour of the world. A combination of agile delivery and super-effective provisioning scripts with a sprinkling of software-defined (virtual) infrastructure. Whilst ITIL v3 and 2011 seem (on the surface at least) to […]
What happens when you ignore service design and acceptance.
I recently discussed service support / operations on twitter with someone frustrated at being asked to provide support for a public cloud service he had very little ability to. Not technical capability, because he seemed capable enough, but access to the systems to do more fundamental fixes. We didn’t get far into the details, but it seemed he was being asked to deal with something which hadn’t been thought about when the service was provisioned.
This is sadly not an uncommon situation among support teams who often have no say in the choice of system/service, no time to get familiar with it, and no means of pushing back on critical gaps even if they do get a chance to see it beforehand. These are often gaps that a 5 year old could often spot, let alone experienced engineers but which seem to be frequently ignored by people whose shopping list only has one thing on it: functionality.
Change requests: get the basics right
Most change requests get raised, authorised and implemented.
When I’ve had occasion to post-mortem a failed change for a new client, I’d usually expect to hear one of the following phrases:
- I didn’t know what I was supposed to be doing
- It shouldn’t have broken that, it was supposed to be totally unrelated…
- How was I to know the backups were running at the same time?
- Wait….I thought John was doing that reboot?
- We only overran because we had to back it out…
…all of which are avoidable.
The single biggest killer of releases
There are many reasons why releases fail. Maybe your test pack wasn’t scoped properly or that harmless application patch from the vendor removed a key piece of functionality. All of these pale in terms of avoidability and regularity in comparison to the following conversation:
Requestor: “I want this change to go into the release.”
Release Manager: “Sorry, the scope has closed, we’re scoping the next one though.”
Requestor: “But that’s too long to wait, it has to go in NOW.”
Sound familiar?
Release Management amplifies the effects of your change process (good or bad)
Let’s generalise for a moment. Release management usually comes into effect in two significant circumstances:
1. When you want to bundle changes into a package
2. When you want to fully ‘transition’ a service into operation and deliver the associated support and knowledge etc
In both of these circumstances, the output of the release will be an amplification of the inputs, ie. the component changes.
Building the Release process in 3 steps
1. High Level
Aligned to your release model, details the major stages of a release: plan, build, accept and deploy and how the lower level activities fit within that: scope, requirements, build & test, acceptance, implementation, early life support and also show checkpoints (scope finalisation, build completion) and show gateways which align to your other processes such as governance, Change Advisory Boards etc). It’s also worth showing which environment various activities take place.
Build a timeline. Start from the ‘go live’ checkpoint at day 0, work backwards (T-) and plot in the major stages for an average release type (you may need one per model) and then plot other activity: environment management (data refreshes, interface switching etc), comms plan and enough lower level activity.
This high level lets you see the whole picture and start identifying areas of contention. If you have release cycles which last for several weeks and which are implemented monthly, you can expect some overlap. Examine these areas of overlap, it’s not uncommon to find the same teams doing different activities at the same time. Does this work for you?
