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?

The reasons for late scope entries are also numerous. Sometimes there are genuine late entries – a new business opportunity with a time-critical factor, regulatory and legal change which needs the full weight of governance and comprehensive testing an established release mechanism gives. But more numerous than the genuine ones (in my experience at least) are the latecomers which were late because someone didn’t read their email advising the scope cutoff date, or didn’t realise it was a hard and fast cutoff, or they simply didn’t do their job and plan to hit it. You can’t do an awful lot about that last one, not actively at least, but there are some practical measures you can put into place to prevent the “I didn’t know” excuses:

1. Easy does it

A ‘glide path’ to locked scope which leads people up to the hard and fast scope closed date, e.g.:

  • Monday: Draft scope
  • Wednesday: Confirmed scope
  • Friday: LOCKED SCOPE

….all of these supported by adequate comms.

Some time ago I had the pleasure of working with Steve from @veralumchange consulting on a project for a global technology company. We had a debate about this point. I was in favour of just giving the Locked Scope date, he argued for the full glide path.

He won. And was right – I’ve seen that approach pay dividends time and time again. People need to see the door closing slowly in order to dart through just in time.

2. Tell them. Tell them that you’ve told them. Then tell them again.

Advertise those dates. Don’t just email them, print them out on big A3 posters giving each release date and the scope dates (include other key dates as well) for the next few releases. Or just the next release.

Once you’ve printed them out, stick them next to repeat offenders. Post a copy on the wall next to the person accountable for your production systems so he or she has an easy reference when someone comes with a sob story about a late addition. Put a copy in the lifts. The canteen. Even the toilets.

Put a small table of those dates in your email signature. Walk round the desks of your usual suspects a few days before and remind them.

3. Have your fallback plan ready (and get your own friends in high places)

Remember – the default position is that the release has been scoped, assessed and locked. This is an exception. There needs to be a solid reason why it should be accepted.

Build a good scope exception process, publicise it, and get some political will behind you. Get someone fairly senior to agree to it and be the ultimate decider when nobody else will agree. He or she needs to carry enough clout to give a final decision and to understand the implications.

Your scope exception process should go through roughly the following steps:

  1. Requestor has to justify the normal change business case, and why it’s important enough to put other ties in the release at risk and why it’s late.
  2. Technical/test teams and architects / design authority assess the late request and its impact on the rest of the release and on the resources who will be impacted both from a functional and non functional perspective.
  3. Release stakeholders and requestor have a discussion about whether to proceed. If an agreement can’t be reached, then engage your escalation protocols.

Don’t overburden your director or senior decision maker though. If you decide to do so in order to make a point, be careful as this can just as easily reflect badly on you. You are, after all, the release manager.

Whilst we’re on that subject…

…and finally

Review your release approach. Is your end to end cycle too long or restrictive? Could you shave time off and be more nimble? Would infrastructure or other resource investment help here?

Ultimately, if you you do everything I’ve suggested here (it can take a few months to settle down) and you’re still getting repeated late scope breakers, then you either have a fundamental cultural issue in your organisation or the release process is too cumbersome for your business.

Every time you break scope, you put your release at risk, reduce your overall change throughput by tiring out your technical teams who have to scramble to catch up with latecomers and set a precedent for the next release. Releases should be predictable, boring and methodical.