Posted by: Jeff Timmins | April 30, 2016

Life can be humbling

Life can be a humbling experience. All around us are examples of things we don’t know as well as we would like. This is a reminder that Release Management is no exception to that rule. The key is to understand this is part of the process of adding value to your organization.

I purchased a car needing more work than originally thought (an example of a humbling CVJointconversation with my wife … create idea for another blog … maybe) so I’ve asked my neighbor for help with some of the repairs. I need lots of help as I have troubles changing my own oil! Per a Auto repair shop’s report I tell my neighbor the CV Boot needs to be replaced (example pictured here) and he starts going on about re-manufactured this, consider the source of the re-manufacturing, where to look for it here and my head starts spinning. After two more conversations and multiple internet searches I am finally able to have a conversation about how to make the correct purchase. Cannot wait for the learning experiences related to the actual repair!

Being a Release Manager can be very humbling as well. As an RM I believe it is important to understand at least the basics of the Solution you support. If you don’t then your value to the organization is diminished (important difference between Release Management and Release Coordination – RMs provide more value). Each time I start a new job I have to learn a new the Architecture and process flow. The task of learning can take a few months and my only advice is to be patient and take great notes – in time you will be comfortable.

Lately I’ve been adding more Solutions to my Release Management responsibilities while hiring other Release Managers to back-fill the Solutions I’ve mastered. Because of that I find myself learning a new set of Solutions (i.e. being humbled again). I find it especially challenging to be an expert in one part of the Organization and someone learning from scratch in another part of the Organization. In time I’ll add the value I want but for now I have to be patient and humble.


Posted by: Jeff Timmins | February 26, 2016

Why Release Management is important

I heard a story the other day about a SaaS provider (disclaimer – I have no connection to this company) that I thought should be shared. This is a great example of why Release Management is an important part of an SDLC and why I think my job is important.

Here is the story [with comments], names removed to hide the guilty.

The users at “Company A” use a solution from “SaaS Provider B”. The users at Company A reported that they were unaware that SaaS Provider B performed a software update [Strike #1 and Rule #1 – inform thy users!]. Sadly SaaS Provider B also introduced a new bug into Production during the software update that Company A didn’t know about [Strike #2 – not good!].

The impact of the newly introduced bug was that the program didn’t actually save all the important/critical changes when users selected the save function [Strike #3 – I’d call that a Sev 1 Bug]. On top of that, Company A then used the SaaS solution to submit their very important paperwork, thinking their important/critical updates were actually included [yikes!].
In the end Company A had to re-submit their paperwork [embarrassing, costly, etc.]. In addition they decided to look for another SaaS provider. 

Regardless if this is true or not (I’m fairly sure it is), it is a good reminder of why it is a good idea to employ a Release Manager on your team.
Posted by: Jeff Timmins | February 19, 2016

DevOps communication done well

Recently I saw a great example inside my company of DevOps communication done well. It was related to a minor update to our On-Prem instance of TFS 2015. This time I’m one of the customers and it was very nice to see that someone took the time to share “inside Release information” with me & the rest of the team.

This was is what the email communication looked like regarding the schedule:

Having not heard any concerns from anyone about the time window for this upgrade, we will be proceeding to update TFS from: Friday, March Xth 23:00 ET to Saturday, March Xth 07:00 ET.  Scrum Masters, please let your teams know that TFS will be completely unavailable during this time period.

This was is what the email communication looked like regarding the changes:

Update includes new features in Backlog


  • Improvements on the web portal: commit details summary is easier to read, and an improved experience for cloning Git repositories.
  • Backlogs: multi-select on all backlogs, drag any item to an iteration from anywhere, Add panel to the iteration backlog, line on the burndown indicates actual capacity, configure settings directly, add/remove users in the sprint plan, and multiple activities per team member in planning capacity for a sprint.
  • Kanban boards: query on columns, card coloring, tag coloring, inline renaming of columns and swimlanes, reorder cards when changing columns, configure settings directly, and hide empty fields on cards.
  • Work items and tasks: tasks as checklist, link to branches and pull requests in work items, task board card coloring, and limit values shown for Work Item type in queries.
  • Build: improved access control for resources, improved source control integration, usability fixes in Build Explorer, and parity with XAML builds for label sources and client-side workspace mappings.
  • Testing: export test outcome for manual tests and test result retention policy improvements.
  • Dashboards: 100% customizable with new widgets and multiple dashboards.
  • Version control: use Git and Team Foundation Version Control in the same project, history and getting started
  • Extending: Service Hooks tab available on-premises

More  detailed  information can be found in Release Notes : Update is installed to non-production environment so you can try it here:


Posted by: Jeff Timmins | February 9, 2016

Loving the Salesforce Trust

Something I’ve always loved about Salesforce is their Trust site. They have made it SF_Calendaravailable for years and it has been my favorite examples of SaaS customer communication done well. They basically say to their customers “we have nothing to hide.”

When I looked at it again the other day I found two features that were new to me. One is the Calendar section and the other is Performance section. Check it out and try to do it for your customer facing solution!

Posted by: Jeff Timmins | January 27, 2016

Ensuring quality

Review, review, review. Verify, verify, verify. Review & verify some more. Such is the life of a Release Manager but is the motivation of a lack of trust or something else?


In the world of political correctness, throwing around the term “lack of trust” is not that popular. Sadly, sometimes it feels like trust is an issue for a Release Manager but maybe there are more socially acceptable words to use?

While thinking of this I noticed something in my email that was very helpful. Since my resume is in a few databases I see a number of RM openings via email. I don’t typically pay much attention but an opening from Exeter, NH caught my eye (I love that corner of the world!). When reading it the following (highlighted) from the Responsibilities section stood out to me:

  • Responsible for Release quality control within Change Management procedures, including the review of pre-Change testing, …
  • Ensures the highest level of quality in technology implementation/releases via thorough analysis of submitted releases …
  • … ensure a repeatable and traceable approach to release processes and procedures.
  • Anticipates release/deployment problems and opportunities and initiates corrective action and/or enhancements when needed.

Bingo! – great terms and phrases for a Release Manager to use to communicate the task of “Ensuring quality.” In particular:

  • Responsible for Release quality control – the need to check & verify details is because the RM has to answer for the Release quality.
  • Ensures .. via thorough analysis – part of the quality control is to dig through the details to confirm the needed information is presented as well as correct.
  • Ensures a repeatable and traceable approach – part of the requirements for most Change Management processes + needed to guarantee deployment success.
  • Anticipates … problems … initiates corrective action and/or enhancements – not only is the RM responsible for review but to make or request corrections as needed.

When asked, a Release Manager could say that they require Release information because they don’t trust the rest of the team. Another option, and probably an easier way to win friends and influence, is to refer to state that the information you require is to ensure overall Release quality and to fulfill the requirements of the Change Management process.

Bingo, issue resolve!


Posted by: Jeff Timmins | October 31, 2015

Making the Release Process better

Not everyone values Process. Not sure why, guess they would rather “shoot from the hip” (a.k.a. do whatever comes to your mind at the time). That doesn’t work for me. I love Process. I want a task to be done the same way each time. Reasons are numerous but mostly because a followed Process stands up to any Audit and internal customers deserve to know what success looks like.

make-it-better-mobileAdditionally, an important part of a Release Management Process is to continually review it for possible improvements. For that I suggest a yearly review of your Processes and if possible a review each six months. This is helpful because parts of the RM Process could be confusing or completed incorrectly or no longer needed because of technology improvements. In the end, you can usually do something to Make It Better.

Here are the steps to follow to complete a Release Management Process review:

  • Review the current Process, noting parts that you (as the owner of the Process) think needs revising.
  • Interview your internal customers (Product Owners, Scrum Masters, Dev & Test leadership, IT Operations, Support, etc.) asking them what is working, what is not working and what suggestions they may have to improve the Process.
  • Interview your manager and their manager asking them the same questions as above + their thoughts on your success implementing the Process.
  • Now with feedback from others, review the current Process again, noting other parts that need revising and parts that need minor revising to become more acceptable to others.
  • Create a Draft of the revised Process.
  • Share the Draft with a few trusted reviewers and edit the Draft as needed.
  • Now send out out the revised Process to all internal customers for a final review.
  • Publish finalized version after making the last minor edits from the final review.

This will take some time but it is time well spent.



Posted by: Jeff Timmins | September 11, 2015

RM Thought for the day – Truth is key

RM Thought for the day – Truth is key

trust-300x225The information that a Release Manager provides should come from what is true. With truth you can build trust. Without truth your information is without value because once found out no one will trust it.

The keys to providing the truth are good sources and the moral strength to report what is true.

Most of the time it is easy for RMs to provide information because it is both true AND doesn’t bother anyone. Information sharing becomes challenging when the truth is not popular with your customers or install Stakeholders. That said, what are your options when people start to complain about “your” truth?

Option #1 – communicate the truth regardless of those that complain, no matter who asks you to change your information you choose not to misrepresent the truth.

Option #2 – lie to make the complains go away – for example lying about the quality of the Release or the deployment requirements or what is to be communicated externally.

Take Option #1 and don’t lie. Lying doesn’t help anyone in the long run.

Posted by: Jeff Timmins | August 16, 2015

RM Thought for the day – the Trap

The Trap of giving into the Loud voice

They can be found in every Organization. They are the Leaders outside of Development and IT that have the Loud voice regarding your Releases. It is understandable they can be heard – afterall they are impacted by your success and failure.

When you hear that voice remember the easily heard voices should be filtered against the Release Management process.

I encourage you to have the greatest level of respect for the leaders of your Organization. Hopefully you even like them. The Trap is wanting to please them more than your emediate management and/or following the pre-approved process.

The warning signs of entering the Trap are easy to spot. It starts when you doubt your process or a particular request tugs at your heart or you just want to end the continued off-process requests.

The 1st step is to establish an exception process. If an off-process request is made there should be method to evaluate it.

The 2nd step is to do the right thing – follow the process. Just do it! Do what your process tells you, what it requires of you.

Don’t take the easy shortcut. Always preform in a way you can easily explain – with self-pride and without excuses when asked.

Posted by: Jeff Timmins | August 16, 2015

RM Thought for the day – I care but not too much

A Scrum Master once told me he didn’t know the details of any given Sprint because he doesn’t want to become too attached. His reason was that with attachment you care about the pieces in the Release too much therefore might lose focus on the main task – getting stuff out the door.

I typically care greatly about the projects I’m involved in. Not sure why, maybe the result of being driven hard by my brother-in-law to be a world-class ice cream scooper when I was young. Anyway, I believe caring is a desirable characteristic of a Release Manager – but there is a limit.

Sometimes I care too much (i.e. tempted to go beyond my process to make sure customers are taken care of) and when I do I have to remind myself to focus my role and let others do their job.

For example, there was a hotfix where the team didn’t make the correct request & didn’t provide the correct details. They were close and I could have facilitated the rest of the details myself. But I didn’t. I stuck to my process. When I don’t stick to my process I’m in the way of a team effort and that can cause problems.

My role is to remind people of the process, remind them their release is stalled and to help them as much as possible without doing their job.



Posted by: Jeff Timmins | July 31, 2015

RM Thought of a few weeks ago – Release failure

RM Thought of a few weeks ago – Release failure

The team responsible for making Production changes to the NYSE computer systems scheduled an update for Tuesday night the 7th of July. Unfortunately the Production change was not found to be not working correctly at the time the Market opened (9:30am ET) on Wednesday the 8th of July.

* Whoops

Per reports, the problem was not investigated until 11:00am – 1.5 hours after the opening. It is possible that reports didn’t get their Help Desk for an hour but it seems like a long delay to start their troubleshooting.

* Not trending well so far

After investigating for 30 minutes the NYSE decided to shutdown their trading systems – and suspend trading – around 11:30am.

* Seems fair to stop the bleeding but please note – the WORLD IS WATCHING! 

After 3.5 (about 3:00pm ET) the NYSE rolled-back the change by switching to backup servers in a different data center. That set of Servers had not yet been updated with the new software. This allowed the market to restart for the final hour of trading. I’m not sure of the details but per reports the outage had little impact to the trading of stocks.

* The WORLD IS WATCHING so probably doesn’t matter the impact.
* Great planning – you had a rollback plan that worked!
* Wow! That took long time to decide to rollback

The cause of the problem was … actually I don’t care. I mean it is interesting why it failed but the Release process main goal is to do no harm. It failed. Customers were impacted for about 5.5 hours with a hard down for 3.5 hours. I’m sure there was a real monetary cost associated with the outage but what about the impact to the Brand of the NYSE? What about all the news articles? Brands can take some poor press but too much can cause lack of trust & people to lose their jobs.

Don’t get me wrong, we all fail but I have a hard time accepting that large of a downtime when you actually have a nice rollback plan. If I was the Change Manager I’d make sure to ask a few hard questions the next day.

Sources & links to articles used

« Newer Posts - Older Posts »