Demonstrating Value

The situation that I found myself in was even worse than I could imagine because my boss had tried to use the CM tool that I was promoting and found it much too hard to use effectively. Given his extensive technical background this was pretty scary and I wondered if I would ever be able to convince him to reconsider his opinion. I have worked with many of the CM tools on the market and ease of use is often a challenge with many of the more powerful CM tools on the market. What I am about to describe could be true about any major CM tool. The firm had already purchased 200 ClearCase licenses from Rational Software. Most of these licenses were not in use and most developers (my boss included) felt that ClearCase was just too hard to use. My job was to demonstrate that the firm’s investment could be recovered and that there was value in making ClearCase the company standard for software configuration and release management.

Disclaimer!

Please note that I don’t work for Rational Software (I don’t have any stock in the company either). I am describing a situation where my company sunk a lot of money into a product and we had to decide if it could be salvaged or we should just cut our losses. This scenario could be true of any other major CM tool as well.

Understanding My Supervisor’s Perspective

The first step in any relationship is being able to understand someone else’s point of view. Frankly, this has been something that I have had to personally work on a great deal. My boss saw CM and CM tools as being overly complicated and wasting a great deal of resources with no measurable return on investment. He wanted CM to be simple. The only two commands that he felt were important were “checkin” and “checkout”. The firm had spent a lot of money on purchasing an industry strength tool and the services of a number of consultants with little lasting value to the organization. It was obvious that source code control was necessary. We just had to agree on how we were going to approach CM. 

Setting Goals

The first step in any process improvement initiative is to set clearly defined goals. I wrote up a short document with three specific goals.

1. All source code had to be secured. 

2. All compile and runtime dependencies had to be documented and secured as well.

3. Developers had to be able to prove that any release in production could be rebuilt from scratch.

These three goals did not require any specific tool and were simple enough that my manager agreed. Fortunately we were able to get his manager (the CIO) to send out a memo stating these three goals had to part of every software development team’s standard practices. Our CIO also directed us to survey the developers on their current practices. This turned out to be a key success factor for several reasons:

• We did learn what the developers were currently doing. In Many cases it was obvious that the code was not being secured properly. 

• Many groups asked for help since they knew that they did not have a strong CM solution.

• We got a lot of great ideas (e.g. best practices) from the survey. I was able to honestly tell people that most of our recommendations came from the developers themselves.
  

Putting the Business Needs First

Many CM practitioners alienate their management by focusing too much on the technology and not enough on why we are in business in the first place. The CM process should help the organization meet it’s goals. The focus should be on providing just enough process and technology to facilitate the software development process. Unless you are a tools vendor, having everyone in the organization become a tools expert is not a good idea. This does mean that learning how the vendor uses the tool is not always a good thing, because the vendor’s developers want to understand the tool perfectly. Developers who work for the vendor obviously want to be experts at their organization’s tools. Too often technical representatives from the vendor were telling people about advanced capabilities in the tool that were just not feasible for everyone to learn effectively. This means that just because the tools can do something does not mean that we should do it! 

Define Your Own Process

We started by creating a process model that included defining each development team’s needs for using CM tools. If a team did not need to use multiple variants (e.g. bugfix branches) then we did not teach branch and merge. We focused most of our efforts on teaching developers just enough about the tool so that they would not have problems and ultimately loose their work. We defined a process for using the tool that included a few recommended ways of getting work done and a number of practices that were strongly discouraged. Just because a tool can do something three different ways is not a good reason for everyone spending their time becoming experts in all of the capabilities of the tool. Instead we promoted one easy way to get work done

Picking the Hill to Die on…

It sounds dramatic but everyone has to choose what is important and what is not. We chose training to be the most important item. We geared up by leasing materials from an excellent training vendor. It was very inexpensive because I gave the classes myself. We pushed very hard for everyone to attend our training. We focused a lot on troubleshooting so that we taught everyone how to deal with the most common problems that came up every day (and caused my phone to ring!). It became clear that people who attended the training could work effectively and those who did not were constantly complaining of problems. Training became and remains our number one priority. We did customize the training to cover an approved method for using the tool, technical skills with the tool and a release process that meets our companies standards. We offered courses in basic usage (Essentials), administration (Unix/NT) and IDE workshops (often informally taught by our peers).

Customer Service

Every developer is treated as a customer. We focused a lot of effort on customer service. To date we have a staff of two supporting close to 200 developers using almost 500 repositories on Unix and NT. We knew that feedback from our “customers” would give our boss a good impression and provide value by helping the other development teams to be more effective. When there were problems, we kept our management updated so that they were never surprised by bad news. We always remember that our work is a direct reflection on the Chief Architect’s Office. Fortunately, our training evaluations were very positive and provided a great source of encouragement.

Putting the Business First

Early on we decided that when groups were not doing what they were supposed to do, we stepped up and tactfully and diplomatically informed senior management. We cheerfully volunteered to help the group get their CM practices in line with that of the other teams. Now we are actually interfacing directly with audit and senior management. Obviously, it was very tricky to be in a position where we were actually “telling on our colleagues”. But we did get a break when a couple of disasters occurred and the loss of source code caused some major problems for the organization. We used these incidents as reasons why we had to make sure that everyone was using the CM tools effectively. Above all else we felt that we had to have the integrity of doing everything possible to protect the company’s source code. This did sound a bit tough, but we found our colleagues regarded this as fair and they respected our position.

Epilogue

The situation was pretty difficult when we began, but staying open and flexible, we have developed an effective CM practice that is widely supported by our management. Remembering why we are in business is the most important step. Then don’t be discouraged by resistance. Sometimes a particularly resistant manager can ultimately become the CM Practitioner’s best support!

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment