Posted by: Jeff Timmins | January 31, 2018

If Release Manager scares you something is wrong

If you don’t want to invite your Release Manager to a planning meeting on most important Release of the year for your project something must be wrong.ScaryBeachPersonHead They are involved to help so why not include them?

Sure, if the person pictured here is your Release Manager they might scare you but are we not supposed to treat everyone equally?

Sorry, got off topic … right … back to the subject, what is the problem that is causing the Development team not to want to include a Release Manager to a discussion about a Release?

Is someone trying to hide something? Are they not interested in explaining their thoughts about the Release to someone else? Are they not interested in someone else having an opinion about the Release? Do they not want other person reviewing the test results? Maybe they are not interested in someone else providing input regarding the best timing or date for a Production deployment?

If anyone thinks that a set of changes are ready to be deployed to Production then it is also ready for scrutiny. Production changes should be an open book, to be reviewed by anyone. It is the Release Manager’s task to provide an environment that fosters open communication, inviting questions and comments as needed. Driving away the RM during the review period only hinders the end product – it doesn’t make it easier.




Posted by: Jeff Timmins | December 31, 2017

Making Progress with Release Management KPIs

In the past I’ve written about KPIs – RM Charter #2 (ITIL based) and Tackling the KPI problem – and I’m happy to report that I have update. Below I wanted to share what data I’m collecting, what I’m measuring as KPIs and what I’m in the process of evaluating for KPIs. I’m also working on KPIs related to change requests but that will be part of a future post.

Data collecting outside of the Change Management System of Record (e.g. ServiceNow)

  • Date of deploymentwebsite-kpis-seo-success
  • Type of deployment and if Code related version of Release
  • Was change request an Emergency?
  • Was change request reset before being approved? (agreed, challenging data to collect but trying for now)
  • Does deployment include downtime?
  • Change request number and Release ticket number (from Development system of record, e.g. Microsoft TFS)
  • Planned and Actual Start time
  • Planned and Actual deployment completed time
  • Actual Validation completed time
  • Planned Rollback time
  • Planned and Actual End time

Data & percentages tracking but are not considered KPIs

  • Count of Code Related Releases (with and without Downtime)
    • Count of Regular or Planned Code Releases
    • Count of Hotfixes or Unplanned Code Releases
  • Count of Code Rollbacks required
  • Count of Maintenance or Non-Code Related Releases (with and without Downtime)
  • % All deployments including Downtime
  • % Deployments including Code

KPIs I’m tracking

  • % Deployments including Hotfixes (i.e. unplanned work) -> Goal >5%
  • % Emergency deployments (i.e. fixing customer impact) -> Goal >3%
  • % Regular Code deployments requiring at least one Hotfix -> Goal >10%
  • % All Code Deployments (Regular or Hotfix) requiring Rollbacks during Deployment window -> Goal >10%

Still developing as KPIs

  • Calculation of Planned Outage vs. Actual Outage
  • Calculation of Planned and Actual complete deployment window time
  • Difference between Planned and Actual Start time
  • Difference between Planned deployment window and Actual time spent
  • Did the deployment window exceed the rollback time without a rollback?
  • Count of Code Releases implemented late (contrary to originally scheduled timeline – includes last Pre-Production & Production deployments)
  • Number of failed deployments (Operations needing assistance/escalating to Development to complete deployment)
  • Number of change related incidents per deployment (Parent Support Cases related to implementation)
  • How successful was the Release? (i.e. how closely did it follow the original plan?)


Posted by: Jeff Timmins | August 31, 2017

Why Release Management

TellMeWhyAfter writing Foundations of RM I found that it doesn’t really answer the question of “Why we do or need Release Release Management?” Here is that answer.

Why Release Management is important

  1. Assists in the Change Management process – creating tickets + collecting details that are required by Change Management in order to simply approvals & easily pass audits as needed. In addition, this also includes representing & advocating for the Development Team when Change Management is reviewing changes with overlapping dates. This is a benefit to the Company as a whole.
  2. Provides or confirms standardized communication of Release information during the pre-planning phase, announcing the Release, during the Release Window and afterwards as needed. This makes sure that everyone who needs to know is informed of the status of the Release.
  3. Confirms details are shared between Operations and the Development Team and that they are understood. This benefits all parties involved.
  4. Provides central point of contact for Release related information in standardized format. Typically this includes future Release schedule information & previous Release performance. This benefits Upper and Executive management.


The postings on this site are my own and do not necessarily reflect the views of

Donnelley Financial Solutions.
Posted by: Jeff Timmins | August 31, 2017

Where should RM be placed in an Org?

From time to time I get comments or questions regarding which the part of the Organization my Release Management group should be included in. Many companies are different because they grow differently so RM can easily land in a different place than others. Also RM is still a growing discipline, which makes it even easier to have different results for different companies.

My experience has mainly been within IT, reporting directly to the main IT Operations Manager. Today I report to the VP of Operations which reports to the CIO.

What do you think? Examples of where I’ve seen Release Management are Development, QA, Product Management, Governance and of course IT. Please leave comments of where you think RM should live.



The postings on this site are my own and do not necessarily reflect the views of

Donnelley Financial Solutions.
Posted by: Jeff Timmins | June 30, 2017

Foundations of Release Management

Goals, Success & Details that every Release process should include


The purpose of the following information is to provide the reader with a better understanding of the motivations and thoughts behind my general Release Management process. With different cultures and histories behind the Development groups around the world, a process that works for one team may not work for another (i.e. one size doesn’t fit all).

In addition I firmly believe that the Release Management process should not be forced on a Development group but should be tailored or fitted to enhance the model that the team provides.

Because of these beliefs I felt it important to share what I call the Foundations of Release Management, a common fabric that to be used for each set of custom designed Release Processes.      

Goals for Release Management

  1. Help Development groups get their changes to Production efficiently and successfully
  2. Ensure controlled, systematic and documented Software Releases
  3. Use readiness checklists based on agreed to standards instead of emotion based Go/No-Go meetings
  4. Communicate details related to Releases so everyone who needs to know is informed
  5. As needed function as a liaison between Development Groups and Operations, Governance, Help Desk & others

What is Success for Release Management

  1. Work with all individuals gracefully and in a respectful manner because everyone is an Internal Customer
  2. Production deployments meet compliance requirements set by Governance
  3. Releases deployed to Production in a timely manner without the need for rollback or causing customer impact (i.e. Production deployment should Do No Harm or Production environment should be as stable or more stable than before the change)
  4. Communicate the right amount of Release related information to the right people at the right time so they can be successful in their roles (i.e. No Surprises)
  5. Limited or no Post-Release issues found in Production

The common fabric of all Release Management Processes

  1. Introductory planning with Development groups (one-time tasks)
    1. Team make-up
      1. Waterfall, Kanban or Agile
      2. Desired Production Release schedule
      3. Review Tools to be used by Development groups, standards for change tickets, source control and Code repository for builds
      4. What to expect for versioning of packages & Releases
    2. Environments
      1. Confirm which environments to be used for Non-Production, Production, Training & DR
      2. Confirm management of deployment schedules for last Non-Production environment (considered Staging), Production, DR and Training
    3. Validations
      1. Confirm validation teams for each Environment, including agreement on usage of non-Development groups
      2. If possible, establish standard validation times and validation processes for each Environment
      3. Establish Release Gates for critical environments (typically covering pre-Stage, Staging & Production), see below for more details
    4. Communication
      1. Main Development group member(s) that Release Management should communicate with
      2. Establish Communication Group that works for particular Application. This could include any combination of Business Owners, Stakeholders, Development group, Help Desk or Internal User group.
      3. Establish information portal to be used for Release Management information
    5. Monitoring & Reporting tools
      1. Understand what is currently Monitored & what type of monitoring available (typically made available via Operations Group, used to confirm Release success & acceptable Deployment windows)
      2. Understand available Alerting (used to confirm Release success) 
    6. Document above agreements
  2. Desired Development group activities participation (in order to collect needed Release information)
    1. Scrum ceremonies as makes sense (as a Chicken)
    2. Scrum of Scrum meetings
    3. WaterFall planning and other update/planning meetings
  3. Release related Communication
    1. Weekly update of upcoming/future deployments to Application Communication Group
    2. Help with communication related to unplanned events or issues
    3. Confirm deployment impact notification is communicated to customers
    4. For deployments – specific notifications related for Application Communication Group
      1. Deployment coming soon
      2. Deployment started
      3. (as applies) Issue with Deployment
      4. Deployment complete
    5. Post-Deployment report providing details of success or failover of the deployment
  4. Release Planning
    1. Regularly scheduled meeting with Development group, providing opportunity:
      1. For Development group to request future deployments not yet known by RM
      2. To review to-do items for already scheduled deployments
      3. To review lessons learned from previous Releases
    2. Documentation of Release details
      1. Key dates for each Release added to a shared Calendar
      2. Add details for each Release to Release information portal
    3. Production Deployment window planning
      1. Analyzing customer impact for each deployment
      2. Creating estimated deploy window timing
      3. Identify which team members need to be involved in Production deployment (see Appendix below for examples)
    4. Leading Development group & Ops deployment planning meetings
    5. Managing Change tickets for environments that RM manages schedule
      1. Create Change ticket 
      2. Requesting needed approval(s) outside of Governance
      3. Requesting approval for Change ticket in a timely manner (i.e. within Governance requirements)
      4. Representing Change ticket at weekly Governance (i.e. CAB or Change Advisory Board) meeting
  5. Managing Release Gates
    1. The output of the Release Gates is a checklist to be used by the Development groups to identify the status or completion of a stage of the Release (i.e. Release is ready to proceed to next environment)
    2. RM tasks during testing in environment before Staging
      1. Identify Release ticket for Release
      2. Confirm Staging in and out schedules as well as Feature Freeze & Code Freeze schedules
      3. Confirm Directions for deployment are available and reviewed by Development group & Operations and request updates as needed
    3. Development group tasks to complete before Release packages deployed to Staging
      1. Confirm Directions for deployment are finalized
      2. Confirm list of change tickets for the Release are linked/associated to the Release ticket
      3. All change tickets and their related sub tasks are compliant and closed
      4. All agreed to Code Testing has passed to agreed to standards (e.g. X% passed, no Sev2/Pri2 or higher bugs introduced)
      5. All agreed to Performance & Security Testing has passed to agreed to standards
      6. If applies, packages are moved to shared Code repository for deployment needs & future reference   
      7. Verify/Confirm contents of build – verify or confirm the code build/package includes all changes expected in the Release (i.e. all code commits from tickets linked to Release ticket are included in the build)
    4. RM tasks before entering Staging environment
      1. Creates Non-Production Change ticket
      2. Creates Draft version of Production Change ticket
    5. Development group tasks to complete before Release packages deployed to Production
      1. List of Known Issues of the Release provided
      2. Rollback procedure has been validated (can be done in Staging or before)
      3. All agreed to Code Testing has passed to agreed to standards (e.g. X% passed, no Sev2/Pri2 or higher bugs introduced)
      4. All agreed to Performance & Security Testing has passed to agreed to standards
    6. RM tasks before entering Production environment
      1. Confirm Code repository is locked down to eliminate additional modification to Release packages
      2. Confirms Production Change ticket is approved
    7. Confirming health and stability Post-Release
      1. Monitor Post-Release Incidents created, identify which are caused by my recent change
      2. Be aware of site impacting issues related to the Solution, typically by having visibility to health checks and/or system monitors & alerts.  
    8. Continually reviewing the Release Gates with Quality teams and Environment team on for possible improvements
  6. Managing Production Deployment window
    1. Create meeting invite before deployment
    2. Lead the deployment call, confirm starting & stopping times of various tasks and status during the deployment window
    3. Confirms Change is completed and dismisses the team
    4. As needed, schedule Post-deployment meeting & documentation
      1. Retrospective of deployment
      2. Update post-deployment details document
      3. Update information portal


  1. List of possible groups that would be part of the Production deployment window
    1. Development group members
    2. Operation team members
    3. Validation team members
    4. Support team members
    5. Product Owners, Business Owners and any other group of people that need to be invited (note that providing optional invites is helpful for some people for extra awareness of the deployment)
Posted by: Jeff Timmins | February 28, 2017

Release Management feels like UPS sometimes

When I think about Release Management I try to ways to communicate to others at work so they better understand why I do what I do. Sometimes “Safe & Successfully Production deployments” just doesn’t do it. Then I started thinking … yeah, I’m like a UPS driver!

ups-tracking_35 I makes total sense if you think about it, right? The way I think about it, if I’m a driver I shouldn’t be thinking or caring that much what is in a package, I should just care that it going to the right place, in the time promised … and that the package will not kill me! Really, I mean if the package is radioactive then I’d say the UPS driver would care about it being in his truck (I’m guessing they have Mr. Yuck stickers but I’m not sure). Same thing with some phone batteries and other live animals. Anyway, I see safety like a code change passing test in Pre-Production – if it passes testing before being deployed to Production it is safe.

And about the address, can you image if dispatch said “Just ask Joe where to delivery this package, he knows and then Sally about the big brown one” and then the driver runs around looking for Joe and Sally to see if they remember. This feels like directions to me – you cannot say “deploy the fix, Fred knows it” and hope to have an environment that allows people to go on vacation.

Then when I think about repeat customers all stories I’ve heard about stores doing nice things for the UPS drivers that take care of them I think of how a Release Manager cares for (i.e. protects) the Operations team.

Like all analogies this one breaks down at a certain point but I think get the idea.


Posted by: Jeff Timmins | December 2, 2016

Join my Release Management team


Looking for a job, experienced or interested in Release Management? I’m building a team to spread Release Management process across Donnelley Financial Solutions.

Currently my team of off-shore Release Managers support 4 different Solutions but we are expanding to support about 40 Solutions! For that effort I have 3 to 4 openings for Releases Managers in multiple US locations. Those locations are


Here is the Job Description

Be part of the Release Management team as it grows to become the central part of managing Releases for Donnelley Financial Solutions (DFS). Responsible for successful deployments, documentation, risk mitigation & communication for Releases as well as Incident Management for the same solution. Responsibilities may cover one major solution, a group of related solutions, or helping our global team with multiple solutions. Most Releases are code related but some also include infrastructure changes.


  • Participate in reviews of current Release Process to find and implement improvement as needed
  • Build & foster relationships with Development, QA, Product Management, Business Owners, Product Support and Executives
  • Work with the Development System of Record (typically TFS) and Change Management ticketing system (ServiceNow) to plan, document, communicate Release details as well as prove Release readiness. In addition, provide transparency and visibility throughout the release process.
  • Track & Manage Software releases through Pre-Production environments to Production
  • Manage risks and resolve issues that affect release scope, schedule and quality
  • Conduct release readiness reviews, milestone reviews and business go/no-go meetings while at the same time understanding system and application dependencies
  • Lead work-hours and/or off-hours Production deployments
  • Troubleshoot deployment related issues as needed
  • Perform other related duties and participate in special projects as assigned

Required Skills

The duties and responsibilities described above are the essential functions of the job.  The qualifications below are representative of the knowledge, skills, and/or abilities required.  Reasonable accommodations may be made to enable individuals with disabilities to perform the essential functions.

  • Bachelor degree and with 2-5 years of relevant work experience OR demonstrated ability to meet the job requirements through a comparable number of years of applicable work experience.
  • Experience with System of Record ticketing products, preferring Microsoft TFS & ServiceNow.
  • Experience working with Development and QA teams.
  • Experience working within Waterfall, Lean and/or Agile SDLC processes.
  • Experience working with Build process is preferred.
  • Able to apply broad work experience and knowledge to the Release process.
  • Excellent communication skills with ability to state messages in a clear manner by using language that is easy for others to understand. Able to explain programs policies and procedures in language that is understood by others.
  • Able to apply excellent functional computer knowledge in utilizing Microsoft Windows, MAC, or other technical tools in completing assignments. Able to apply expertise in all the tools or applications used to complete work assignments.
  • Able to modify communication style both formal and informal to match the appropriate level of the audience targeted. Requires strong understanding of the impact of a message on the organization or customer. Able to write with the clarity and precision necessary for the work being performed.



Posted by: Jeff Timmins | November 30, 2016

What to call that Release?

A Release is a Release is a Release? G. Stein (revised)

Are names of Releases important? Should the Software/Service Industry care what we call it Internally or Externally?

From my memory of the shrink-wrap days of Microsoft, they put out regular Releases, Service Packs and Hotfixes (KBs). The today’s Cloud World we see fun names for Releases “Winter ’17” or “Serengeti” but Service Packs and Hotfixes are not well published. When you see a version like “” you get the hint that this is not the original Release but it doesn’t scream “I’m a Hotfix”. Customers of SaaS vendors that throw around Hotfix too many time typically move on to another solution.

Why should we are about Release names anyway? Why can’t we just call each Release brucesBruce? I mean we could call everything Bruce and while that would be fun and easy to remember it might be confusing for normal people. But I digress.

Release names are important! They help us understand and easily discuss what change happened + it sometimes helps understand why the Release was important. Great but what about “fixes” to the main Release – should they have distinguishing names as well? My vote is “Yes please!” for the same reason that Release name or number should be unique – I’d like to know what Major Release that fix was associated with. This comes in handy during Support calls (what version are you using?) or building a Non-Production environment (I need version X in Staging please) or discussing past or upcoming Releases with Staff (Release Y for Project Llama on Saturday, Release 1 for Project Sam on Tuesday).

Great, names are important but what about the term “Hotfix”, is that necessary to use anymore? I have to admit I have used it many times over the years as an Internal label but I’m being challenged to stop that practice. Why was it important to use before? Because I wanted to track problematic Releases and look for trends that caused it. (Due to tracking I was encouraged to decrease my Release schedule in late December and early January, when I did Release quality increased!) That said, my tracking needs don’t require the label “Hotfix” to be shared with 400 Internal Customers. When it is shared, those Internal Customers could start to develop a poor attitude towards the creators of the code. As long as I have a build number or use a label like “update 1” I can track the Releases and keep track of which “update” was planned and which one requires a Root Cause Analysis (RCA).


Going forward I’m dropping the Hotfix label when communicating Release names – how about you?

Posted by: Jeff Timmins | June 30, 2016

Release Management because no one is perfect

To really show imperfect I am I’m going to finish this blog Friday

Posted by: Jeff Timmins | May 30, 2016

Invisible Release Management

Can you see your Release Manager? Is “No News” the same as “Good News”?

The other day I was part of a meeting where Managers gave “shout-outs” for a job well done. Maybe I’m a little too self-confident but I kept waiting for someone to mention my name.

Not surprisingly that comment never came. Then I remembered … I’m the invisible man … no wait, I’m the Invisible Release Manager!

I use the term “invisible” because the Release Manager role is not even noticed if the job is done right. Because of that I really shouldn’t think that anyone would notice. In my first Blog entry titled RM Charter #1 I wrote about the same concept but honestly it has been awhile since I thought about it:

“In addition, RM done well is an invisible process to the customer and to the company as a whole.  This goal is definitely applicable to SaaS (customer focused) and thus easily transferable to a SaaS company.”

I love doing my job well and I have to admit I would love it someone actually too the time to notice and provide positive feedback in a group of my peers but I shouldn’t expect it. Hopefully your management or other leaders are giving you positive reviews of your work – if not I encourage you to find a group of peers that will.


Older Posts »