Print Page | Report Abuse | Sign In | Join
Please release me, let me go! To waste… would be a sin

Please release me, let me go! To waste... would be a sin

Jon Morley and Rob Spencer describe ITSMF UK’s first Release Management masterclass, which they facilitated in September.


With 16 delegates from across the country – representing a wide array of public and private sector organisations – we knew that there would be a broad range of views and perspectives at our first Masterclass. The event blended breakout sessions, the occasional bit of theory and a lot of experience to help answer numerous release-related questions.

Usually, Masterclasses involve very specific delegate scenarios; however since the requested range of topics was quite broad, the day was based around ‘Dagen H’ –  the day that Sweden moved from the left to the right side of the road in 1967 – to see if release management could help. Fittingly, the song quoted in the title of our article was also released as a cover version by Engelbert Humperdinck the same year.

Changing sides of the road might seem an inane subject to tackle, particularly for ITSM practitioners, but we purposefully chose a subject not typically associated with IT release management to break delegates – and their facilitators – out of their comfort zones.

Very quickly we all spotted themes of commonality between deploying IT systems and deploying other resources like road signs and GPS map updates – yes, we agreed that GPS existed in 1967!

Going back to the broad range of topics, we would like to share with you some of the learnings we took from the day that may help you on your release management journey.


1. Keep it simple


There are only so many ways of getting from release preparation to successful delivery. You don’t need to complicate things but you do need to recognise and respect the specific requirements of your stakeholders and the subject matter.

We used a simple Plan > Build > Accept > Deploy approach.


2. Clash of the titans – release versus change

Not surprisingly, this generated a lot of debate. Whilst most attendees liked the split between functional and non-functional as delineators for release and change, others preferred to use scales of complexity or situational judgements about whether a change warranted being formally ‘release managed’. 

Rob asked the fairly challenging question, “Do you think the difference between change and release is something that concerns us more than it concerns our customers?” 

The answer – perhaps unsurprisingly – was a resounding, “yes”.


3. Scoping releases


This can pose its own set of problems, but consider the following when scoping releases may help: 

  • Timelines (e.g. a schedule)
  • Governance (controls, gateways and checkpoints)
  • Activities (environments and resources)
  • Sizing (deployment windows, number of days’ effort, operational impact and so on)
  • Priority (by business area, MoSCoW methods etc)
  • Proactive approach (consider locking scope and fixed release slots. This may suit a daily or repeatable cycle)
  • Reactive approach (waiting for a request to release or deploy and plan around the request candidate. This may suit a monthly O/S security patch cycle)
  • Methodology – do you use Agile, Waterfall or something else?

4. Consider the role of your release manager


There are many types of release management role – but depending on how/where you position your RM function, you might want to consider the following:

  • Technical – often focused on deployment, code or specific technology. This approach is good for version control and low-level tracking but can be in conflict with other technology sets or customer focus.
  • Implementation – this usually focuses on the dress rehearsal and/or implementation to production. It has effective control over deployment to live but is often left to the end of the project – constraining time and effort.
  • Project & scheduling – usually led by a project or environment manager, this focus on planning releases to various environments during a project. Should you choose this approach, ensure you consider early life support and that loyalty doesn’t solely lie with the project side of organisation.
  • Business relationship – a collaborative, content-driven approach between business and IT. This is good for shared governance, but caution should be used to ensure that there aren’t conflicting agreements between different stakeholders or too much focus on the short-term objectives.
  • Enterprise – a more senior role with delegated authority for the release manager with visibility of multiple streams (project and non-projects) and the ability to resolve any contention issues. Often, this requires a team of analysts and SMT buy-in to implement.

5. Continuous delivery, agile, DevOps and waterfall

  • Consider the Windows 10 fast/slow preview programme as an example of customers choosing to sacrifice some stability for responsiveness and new features – could you adopt similar principles in your organisation?
  • Think about automated test and deployment to support your environment – regardless of methodology
  • Don’t be afraid to use a hybrid approach. Delegates compared and contrasted tradition/waterfall with a more agile approach for Dagen H. Whilst some expressed a preference towards one or other, the majority came up with the idea of mixing both agile and waterfall as the situation required – echoing Gartner’s Bi-Modal IT model.

6. Tools

  • There are a plethora of bought tools you can use for managing/tracking, build/deploy and Desired State Configuration (DSC)
  • Don’t be afraid to develop your own home-grown tools. The delegates developed checklists and a ‘transition map’ – Rob’s rather grand name for a diagram that lists all routes to production in order of risk/impact/complexity
  • Whatever you use, ensure you and your stakeholders can see at a glance how any given change may move from start to finish
  • Equally your tools need to be useful for release management and reflect the scope of change they have to deal with. Decide which types of change need to have the release process wrapped around them.

Whilst most ITSM professionals won’t be involved in helping change the side of the street we drive on, we can help our release managers and customers benefit from delivering more, and breaking less, by continuously improving our approach to people, process and tools.

The feedback from those attending the Masterclass was generally excellent and delegates left with an array of resources including slides, whitepapers, a book and, above all, the shared experience and learning gained from networking with their peers. As someone who has been a delegate and a facilitator, I recommend Masterclasses highly – particularly if you have a new scenario you would like put forward. For more information about the ever increasing range of Masterclass topics, please consult the ITSMF website or office.

If you’re interested in knowing more about the ITSMF UK Transition SIG, please contact Matt Hoey via the website, join our dedicated LinkedIn group, or follow us on Twitter: @itSMFUKTransMgt, @JonMorleyITSM, or @ChangeRelease.


Jon Morley and Rob Spencer are vice chairs of ITSMF UK’s Service Transition SIG. Rob is a Service Transition & Improvement Consultant at the Financial Conduct Authority and Jon is Service Transition Manager at the University of Nottingham.

Premier Gate
21 Easthampstead Road
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us