My journal of the adventures and activities that I enjoy in my life. Some posts will be work related. Other posts will be family related. A smattering of me is what you will get by reading this blog.

Wednesday, February 19, 2014

Release Management : planning meetings

After avoiding the obvious for a while now, we have decided to institute recurring planning meetings to cover only Release Management tasks. Heretofore we allowed these conversations to occur naturally, when needed, and with whom needed to be present. This usually involved someone in the development arena talking to someone that would push code changes into production. Few more were involved. And to the detriment of others, others were not always included.

The good of this method of informing of 'need to change' is that it is organic, non planned, skips meetings (everyone hates meetings) and has the randomness that is requisite at times to be agile and allow change to occur. A process was still followed, but it was executed at random times. This is a plus to those that want to keep light on their feet.

The bad is that this method forces change into a system that should and could take a bit more planning prior to execution. Regardless of how agile your development teams want to be, changing production is fraught with potential disaster. Small change or even well choreographed large change can impact a system minimally and leave no lasting scaring. However, rushed, inconsiderate change, can wreak havoc. This is the type of change that is likely to occur in a rushed or unplanned manner.

So a process was instituted at least at the inception of the change request so that several necessary tasks could flow upon knowledge of an impending change. If we stuck to the task list and performed them satisfactorily, we were usually successful. Not always. But usually. Tweeks occur as time passes, and the process is tightened.

Fast forward to today. We now realize that this method of singular knowledge sharing with a select few was detrimental to others in the organization. Some poor business analyst on the north end of the building had no idea that one of his favorite tables just suffered a drastic change and the fields he commonly referred to in his reporting were just altered inextricably, and he had no forewarning of said changes. No one thought to let him know and his reports now suffer. Sad. But no one knew. Well, someone knew, eventually, but to the chagrin of those displaying the information to others, probably some executive in a plush conference room. Oops.

So we now have instituted a recurring meeting (uugghh, peal the skin from my face would be a better use of my time...). In this meeting, we invite many. Hopefully all. But for now, many folks. These folks were chosen for their potential interest in change to our production system. They now have the option to attend a brief meeting and hear discussion of potential changes to the production system. Here is a forum in which they can ask why, when, and why. Conversations can begin here and continue to the satisfaction of all parties. Plans will be made as to when the change will occur. Bartering as to how this change can be introduced with the least impact will ensue. Parties will be informed, knowledge shared, and life will move forward.

The changes will still involve a select few. The process to perform the change and even prepare for the change will remain similar to before. Tasks being accomplished, questions asked and answered, plans created, testing, and so on. But with this little recurring planning meeting, folks are informed. Change is much less drastic and caustic. Acceptance can begin much earlier in the process and anything needing to be tweeked to allow and accept this change can be implemented much earlier in the process. No more waiting for someone else to point out the flaw, later in a meeting, and hopefully not in front of C level folks you are trying to impress.

Start with small tweeks to your Release Management process. See how you can improve it. Add some oil here, change a gear there, and before you know it, your machine that drives and introduces change into your production topology will be so smooth you won't even hear it purring along gracefully.

2 comments:

Interesting. I've been in both places. Both small, ad-hoc groupings to release changes and large, formal, weekly meetings with changes.

The problem with both is that people only want to know what changes will affect them WHEN they will by affected. It's almost like people need a subscription of the items that are changing that they use. Of course, automation, tracking their activities, would be nice.

The big thing I'd suggest is that you have a scribe/secratary at these meetings, which should be optional. Once information is presented, ensure there is a publication of the changes available (along with others) so anyone that wants to know what will, or has, changed, can find it.

That is a great point. I hope that we can publish, before the meeting, the topics to be discussed in the meeting. The actual changes to be discussed. And that this information will draw the right people to the meeting. Then, as you say, those discussions are actually recorded as well. It makes it more thick, but information is thick.

My Twitter Updates

About Me

I love my family, my wife, my 3 kids.
I love to ride my dirtbike, play raquetball, waterski, wood work, paintball, geocache, snowski.
I'm a Microsoft SQL Server Database Administrator living in Utah.
As I look back on my life, I realized that I needed and wanted to document these different activities, for my own record.
This will serve as a journal of sorts on those adventures and activities I enjoy in my life.