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.

CareTooMuch
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

Posted by: Jeff Timmins | June 13, 2015

Therapy for Release Manager

Therapy for Release Manager

Most people need to take a mental break from their daily jobs in order to remain sane. For the Release Manager working on a team of one (i.e. no direct reports), the need is a little greater due to the nature of the role.

From my experience the typical RM is continually negotiating Release dates & Pre-Production validation status as well as borrowing or persuading people to work toward their project. Having a high amount of responsibility that require on-going discussions can be mentally draining. Because of that it is important to entertain your mind with a different type of project while away from work.

Table-wpid-20150312_183443-500x282

Outdoor Table

I’ve always enjoyed bicycling and photography because it has been great therapy for clearing my mind as I focus on something completely different. I’ve started to build wood furniture after work and that adds another dimension to the therapy – full control! (Okay, semi-control as the Product Owner – my wife – has the final approval.) The fun part is that I’m not dependent on anyone else to complete the work. I set the delivery dates, I have a lot of control over the design, I source the materials and only sometimes the Product Owner rejects my decisions.

PlanterPost-wpid-20150520_192508-291x516

Planter box with post for outdoor lights

Quality (QA) is another interesting difference in my wood projects. At work, I have high expectations for overall project quality. At home, my word furniture only needs to be at a “good enough” quality. I do care about how my table looks but imperfections are acceptable and “adds character” to the piece. Also I will “increase quality” if needed when making the 2nd version of something but I will not throw-away the first version. It is almost another part of the therapy, living with “good enough” when I require perfect the rest of the day.

Note that I’m not trying to sell my furniture to you or anyone else but wanted to encourage you to find something you enjoy to keep your mind fresh. Furniture creation is not for everyone but works well for me.

Enjoy!

 

 

 

 

 

 

 

 

 

Posted by: Jeff Timmins | April 30, 2015

Tracking Release Runway Part 2

Tracking Release Runway Part 2

Regarding my previous post Tracking Release Runway (a.k.a. “Part 1”), after using the “spreadsheet view” for a few weeks I realized that a calendar view would be very helpful when discussing this information.

GDoc Runway Tracking CalendarThe reason behind adding the calendar view was that when discussing start and stop dates of a projects I could tell people didn’t see the impact of the concurrent projects. Once I offered the calendar view the project teams understood conflicts thus making it easier to discuss compromises. (For our projects the conflicts deal mostly with testing capacity.) My guess it is easier because our brains are wired from years of training of seeing dates in a calendar view.

Because I still wanted a view to track all data related to a project (detailed in Part 1) I the original as “Main View” and named the other tab “Calendar View” on the same spreadsheet.

GDoc Runway Tracking Tabs

 

 

Because I have not automated the input of this data it requires a double-entry effort on my part but with around 6 projects that is not a large burden.

Posted by: Jeff Timmins | April 27, 2015

Don’t show dirty laundry in public

Don’t show your dirty laundry in public

Seems like a simple advice, something you might have heard from your mother … but because good lessons are often worth repeating … When working through the “whys” of a failure, it is best to only include those that were part of the failure. Omit from the conversation Executives or Project Leaders until you fully understand the failure and the cause.  
5279158209_ba33fe6a99_bIt is fine to include high-level people on your emails when you are reporting the final summary of a project failure or when a little pressure is needed to get traction on a question. That kind of “laundry” is fine.

What I would consider poor communication or “dirty laundry” is making a fellow worker look bad in front of their boss’ boss’ boss or asking them to defend themselves for something that might not be their fault. I understand having to report status or root causes but the right thing to do is to get the correct information (via emails or meetings) from the people involved. Once you have that it is the right time to report your findings to Executives or Project Leaders as needed. That way you a) don’t make people look bad on accident and b) you provide the busy people with a concise summary instead of 50 emails going back and forth.

Relationships are important, especially for a Release Manager, so don’t needlessly damage them. In addition, time is important to everyone so be careful whom you include on your emails.

 

 

Posted by: Jeff Timmins | March 27, 2015

RM Thought of the Day – Reducing Chaos via isolation

Release Management thought of the Day – Reducing the Chaos via isolation

Recently I had to stand up for “best practices” for Release Management and came up with the following short description of “why I do what I do.” Here it is:

The goal of Release Management is reducing the Chaos associated with Production Change. Among other things, to support that goal I believe that:

  • Changes should be isolated as much as possible (i.e. one or a limited amount of changes to Production at one time). When changes are made in isolation, Pre-Production validation is easier, impact to the Production system is minimized and if there is an impact it is easily identified.
  • Various teams need to be prepared for each Change
  • Changes should be properly validated in each Release Gate (i.e. no shortcuts taken unless the walls are burning down)

 

 

Posted by: Jeff Timmins | March 18, 2015

Branching models

Branching models

I’ve understood the software build process for a number of years but it wasn’t until I worked in Synacor that I understood branching. The concept of a Hotfix branch is simple but understanding the inter-workings of branching process a little more detailed.

Build graphic from Vincent Driessen’s site

At Synacor the Release Managers were responsible for requesting builds so I had some things to learn. I remember it taking a few weeks to understand the difference between the Master & Live branch and how to request successfully a build from the multiple Git repositories.

If you don’t have Russ, Jessie, Mike & Garrett around to help explain branching to you can turn to Vincent Driessen’s great explanation at “A successful Git branching model.” This article was written for a Build Engineer/Release Engineer but if you can skip the Git commands if you so choose.

Of course there are other explanations and other examples available other than Git but you will not go wrong knowing this standard model. Git is a popular code repository so it is a great place to start learning about branching.

 

« Newer Posts - Older Posts »

Categories