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.