Posted by: Jeff Timmins | July 14, 2013

Failure in Release Planning

Release Planning is an important part of Release Management and when it fails, it causes inefficiencies throughout the company.  Here is an example of a failure in Release Planning:

Planning failing 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • Internal customers adds an entry to the Release Calendar on his own for a time 12 days away on a day that is almost always a Production blackout day for his company (i.e. Saturday).  They then send an email to only one of the Release Managers stating “this is the date I need per my external customer’s request”
  • RM replies back adding a few people saying “hold on, not sure if this will work, have to check with my boss”
  • Boss of RM says “heck no, please push back on that date”
  • Internal customer’s boss gets involved replying back that it is important to meet the external customer’s request, maybe there are options to release the code earlier and then turn-on the functionality on the customer requested date but also states they are not sure if we can meet those Development requirements
  • Development Manager is included in email and replies back stating this is a good idea but we don’t have enough time to make it work like that then brings up the question of how this unscheduled change request relates to the upcoming scheduled release (i.e. this could impact the runway depending on what they want, do we know what the customer wants, etc.) – basically further research is needed on customer’s needs
  • Internal customer adds PM to the email
  • Days go by without another reply to the email thread

Problems that cause the failure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • Everyone has write access to the Release Calendar
  • No process for officially requesting releases
  • Internal customer failed to request the RM do actually “manage” a release for them
  • Non-standard release requests should be a conversation not a demand
  • Too much dependence on email conversations instead of one on one or meeting conversations
  • RM has to react instead of being given the chance to help the internal customer create a plan for the company to meet the customer’s needs
  • In the end, the Release Management role is not seen as a resource to manage how releases should best be deployed but more of a coordinator of whatever an internal customers wants

 

Advertisements

Responses

  1. We would never open up the Release Calendar for PMs or anybody else to claim a date in the first place. The Calendar is a lockbox; any particular date may have competition from projects, infrastructure or maintenance tasks, and support resources must be requested and scheduled just as RM resources. Any out-of-band, off-cycle or emergency request must first appear before a review board, then goes all the way to the CIO for approval before ever getting a date from Release Management.

    Your scenario is perfectly familiar to me, however, from the way things worked not so long ago – before there was a Release Management. Most shops would recognize this as all too familiar in practice.

    • Happy for you and happy that as a Release Manager you had the control to make such changes. Some of us are not as lucky/talented/time as you.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: