One thing I am always looking to improve upon is communication. One method to improve communication, is to improve the tools you use to communicate.

Imagine: You’re a build engineer, and you get a request to make a small configuration change to the build environment and to execute a development build. You create…better yet, watch the video below. It is a great example of how you could use Google Wave in an business environment.

When working on a much needed update, or new feature for my users it is very hard to get the rest of my team to not spill the beans. Of course, they mostly wonder why I am so secretive and the answer is – expectations.

Why I Stay Secretive
I found that when my group announces that we are actively working on something, no matter what we say, an expectation is immediately set. It can vary from how the feature actually works, how it was implemented, or when it will be implemented. Then you get questions, and people bugging you non-stop when you are going to release it. It becomes a mess, one that I don’t like dealing with. So when a co-worker casually stated that they would discuss the changes in a upcoming meeting, I couldn’t help but scream “Don’t tell them yet!” Good thing, because that was 2 weeks ago.

So What Is This About?
For the past couple of weeks, I’ve been working on such an update for our users. This update introduces a new look, news feed, tips section, integrated wiki search and a few other things I can’t say. It is all part of my rescue mission to improve communication and to make things easier to find.

And When Will You Tell Them?
Monday. The update went out after 90% of the people left for home. It looks beautiful and best of all, it is 100 times more useful to me now and I hope that starting Monday it will be useful to everyone else. So by the time users have it and to the time we officially announce it, they will know how everything works. Therefore, I get away scott-free with no questions.

Maybe next time I will announce that my group will announce an exciting new announcement as some point in the future?

When you work in a small team and you support hundreds of users, communication is vital.

The Cause
Over the past year, my team has picked up several new users and applications to support with our software configuration management (SCM) process. As word gets out about the services we provide we continue to get new users and more applications. Being such a small team, this presents a problem with support.

The Problem
With the new apps, new users, we simply can’t keep up. Small requests that would take a second to complete are sometimes ignored because we spend our time on support. Why? Mainly because we fail to advertise our documentation that will help reduce user calls.

The Fix
The first step is to clean up our documentation. I have been taking a look at what we got and organizing the flow of the documentation for the benefit of the end user. To find out how to fix the problem, you have to know if you are the cause.

The second step is to advertise our documentation. I have included links to the documentation in my email signature, and now I simply answer half of a users question and refer them to the documentation for more info. I have also began to test a news feed to publish tips and faq items. These news items will be auto-delivered to a users email box if they subscribe.

The third step is to make everything useful. My team deals with a lot of information. Sometimes it can be too much for the end user to take in. After cleaning up the wiki for the users, and creating a publishing process to share commonly asked questions, tips, and other info to reduce calls, I am updating the users reports.

We provide a internal web site where users can get all the info they need on their projects. Basically, they live off this site. I have begun to update the usability of this site and add a few things. These few things I am adding are all of the above. Available on their reports are a new look, new navigation method, and dynamic information being fed to them. It has already received great feedback in testing.

What’s Next?
Complete testing of the internal site. Continue to gather user statistics from our Wiki and use that to provide even better service to our users. Of course all of this is just a consolidated, recap view of what I have done but it has worked thus far. Once I get the site pushed out, I think it will be ever better. I can finally go back to surfing the web at work instead of actually working.

I came across this video and it just spoke to me. Therefore, this video will be 100x funnier to me than it will to you. Besides, you can never get enough of the various subtitled versions of this video.

This video quickly reminded me of just one of many recent events. A unit test caused the project teams build to fail. One would expect the team to fix the failed test but instead they opted to place the file within an ignore list. My reaction was similar to this:

If you missed my 2 part Life In SCM posts you can read up if you are interested in learning about what I do as a Release Process Manager in Software Configuration Management. Where I last left off, I was discussing my role to becoming the brand awareness guy within the group. One of the things I love doing is taking feedback/enhancement requests and implementing them for the user. One of those things was providing a better interface for our developers and project leads to interact with. This interface allows them to view their development builds running in real time and allows them on-demand access to execute the builds when they need them. They also receive trending reports, test results, and more.

Now because this is something that drastically changes how our team interacts with the product as well as how the project teams interact with their product, I wanted to keep this very quiet until we were ready to launch it. That didn’t happen. Before telling the users what we have done, I wanted to get documentation and proper procedures put into place amongst several other things that I felt needed to be refined before unleashing the news. Instead I had to go into full support mode.

The news about our new application was “leaked” or rather spilled to various users so I started to receive calls about it requesting access, asking what it does, wanting to test, request new features for it, etc. So, I had no choice but to “announce” it to a crowd of people that didn’t care because it was old news. My original plan was to announce, link to documentation, and have users get instant access to the app. Instead they were told before hand, the documentation wasn’t complete, user access wasn’t given yet, all the code-bases were not entered, and I had a group of people screaming at me like kids in the back seat on a road trip.

Leaking stuff before we are ready seems to be a common theme. Team members freely talk about our next set of features to everyone they can and they raise the bar so high that I am not sure if we can deliver it and when we do it will be met with a ho hum attitude followed by a “about time” comment. If I can’t control the leaks within my team, then how the hell do organizations manage to keep some things secret for so long? Must I threaten the first borns of my teammates?

Life In SCM continued…

One of the things that always freaked me out about my new job was that I was automating it. I was preparing the development team to move to an automated process that would do 75% of my work. That left me wondering where I would go once the automation was complete. That is certainly never a good feeling to have, and it doesn’t help when your co-workers start asking you that same question.

I pressed on with the automation because it was something sorely needed for the development team and myself. Our code-base was growing, our projects were growing, and our development team grew.  Project managing our semiweekly and large monthly releases, while training developers, upgrading our web environment, and going to school full time took its toll on me. 10-12hr work days were the norm, and sometimes even went beyond that. Manually cross checking our code-base and reviewing check ins, revision number changes, deployments to delta, dev, and beta platforms was just a chore. Though the automation was the light at the end of the tunnel.

What is this automation I speak of? It was a true CM System with change management controls in place. This tool replaced one major document I used that tracked all changes, approvers, and testers…sorta. See this release management document kept track of all bug fixes and enhancements. It tracked the reason we were making changes to the code-base as well as tracking the files and revisions used for that particular change. With this new system I no longer had to do this manually. The developers tied their change to a request and it automatically tracked it through automated reports. This automated report was updated several times a day and only took minutes to create while my manually created code analysis reports took 3-4hrs per release and I updated it weekly. This system also enforced code reviews, code security, and proper deployment procedures as well. To me this tool was all I could ever ask for and more. After spending 1 year on the job, I went from loathing my work to now enjoying it.

Oh, you think that was all? You think the implementation of this cool automation tool sprouted flowers with singing birds and dancing squirrels? No, not in the least. If anything, it made my cube a red target. I became the guy to hate. Yes. The developers hated the new process. They hated the restrictions. They hated change. It didn’t matter that this process re-inforced our audit procedures. It didn’t matter that this new process guaranteed us a solid code-base. It didn’t matter that this new process gave them all the tools and reporting they ever wanted. It didn’t matter that they went from being supported by 1 guy, me, to a team of 7. None of that mattered because the process sucked, and I sucked for forcing them to use it.

This is where the real battle began…

I figured I would write a little bit more about what I do for work. I am a software configuration guy. Meaning I track changes to the code, build code, manage release process, and maintain environment. Let’s start with my entry into SCM…

At my previous company I began to administrate and develop for the Remedy system. We tracked all changes in IT with this system, and I produced all the reporting, and tool for submitting change requests. I also began to run one of our change control meetings for the desktop group. I was then thrown into change control. While performing my new duties I wondered on several occasion’s on how this development team can code something, release to prod (internal app that produced material for clients), and not have anyone test. Not only that but they would throw a fit if you contacted them about some bug or failure? Change control that really isn’t controlled, huh.

Fast forward to my new job. Hired as the software installer for a java web application. My tools were Ant. I was tasked with building and managing the code base. Research new tools and methods to improve build process. Work with developers and testers concerning application errors, maintain release schedule and maintain build environment. Fun. The first thing I realize was that I leave after the developers do. Did I mention everything was done manually? Dev’s would update code and check them in. I would pull said changes based on what they entered on a sheet, build, create a zip, and deploy to a testing platform. I then would track what went to what platform as well as who the tester was, what the changes was for, etc. I would archive the zip and track any others changes needed. I needed to know ever detail about what was being installed to a platform. Knowing every detail to make my job go smoother, added more work thus making my job more difficult.

To get a sense of scale, our production only installs happened Tuesdays and Thursdays with the big projects happening monthly. We also are a parallel development house with at minimum 4 major monthly releases in development. If you have a 4 week month then I would have 6 minor production installs as well. Things got a bit crazy for a while. One man armed with several excel spreadsheets, a pen for approval signatures, and a beating stick for developers, I became the savior that was hated by all. Another kind of hate was forming though, a deep hatred for my job. With our releases getting bigger and bigger. With our minor releases doubling what we typically install in a month and with new technologies being added and major environment upgrades taking place, I found myself burned out on a full time school load and 70+ hr work week. I had no one else to help me. It was just…me. No vacations, no early time off. I had to be there early and leave there late in order to deliver by deadline.

It wasn’t until almost a year ago I was saved, and the light was oh so beautiful…

Life In SCM PT.2