Change Management – Unfreeze – Move - Refreeze
Organizational Change involves getting people to realize that they have to change the way that they work. For CM this often involves defining how software developers will management their source code and release management process. In my work I teach hands-on ClearCase classes. I have taught over 250 developers on both Unix and NT. During the class students are interested in improving the way that we manage our source code. I teach how to use the tool and I focus on how to create an effective release management process. The tool alone will not safeguard our code. The tool used correctly will! In the classroom I have their attention and my students are usually open to new ideas and changing the way that they do things. How can I keep them from just reverting back to their old ways of doing things? For example, developers using ClearCase who don’t bother to check in their code might as well not be using ClearCase at all! (We actually address this problem by proactively sending out “Aging checkout” reports.)

CM Planning Can Be Used to Reinforce Training
All of our CM Plans are posted on an intranet for anyone to see. There are two separate documents involved. The first is simply a training document that explains which commands can be used and which one’s are not to be used at all. This document also includes a service level agreement and is essentially a contract between the developers and the ClearCase support staff. (It is noteworthy that we only have two full-time and three part-time ClearCase support people serving 300+ developers worldwide.) Many development tools are feature rich. We try to give our developers some guidance on what features they need to use and which one’s should be avoided. These are best practices that we have learned from our own direct experience. Some tools vendors include features just because it looks good in the marketing literature. We try to specify one good way to use the tool. And we try to keep it very simple.

Goals for CM Planning
Our primary goal in CM Planning is to allow developers to understand the rules of the road for using ClearCase in any development team. This facilitates our best developers moving from one project to another as needed. If a developer knows how to use ClearCase he or she should be able to read the CM Plan and understand how their new team uses ClearCase. We also make CM Planning easy because we have templates setup so that each team just has to fill out a template and in minutes they have a full-fledged CM Plan.

Organizing Metadata
Modern CM Tools are essentially a data warehouse for source code. Version Labels, Branches, Defect Numbers and Version history provide a massive amount of information for the developer as well as the project manager. Used haphazardly this capability can be confusing and misleading. I have seen developers loose their code when they did not understand the branching mechanisms in place.  The CM Plan is a great way to standardize on naming conventions for Version Labels and Branches as well as other metadata. We decided that Version Labels will be used to define a Production Release and that branches will define Variants in the code, such as defect resolution to a Production Release. The CM Plan provides clarity to what can be a confusing and complicated mess of information. From a process perspective, we appoint the Buildmeister as the single point of contact for Version Label and Branch creation. Developers must request a branch or version label from the Buildmeister. The role of the Buildmeister as well as naming conventions are defined and published via the CM Plan.

SDLC
The Software Development LifeCycle could also be defined in the CM Plan. Although, it is usually not a good idea to use Version labels like “Production” to indicate the status of particular release. The CM Plan can indicate the TRADER_RELEASE_2.0 is in integration test.

Organizing for Success
We find that posting a web page with dynamic information such as release target dates and contents of a release. This information can also just be specified in the Release Notes or a README file.

Change Control
Most financial services firms do not use formal Change Control. The Project or Development manager usually decides what changes will be made and which release that they will be made in. Flexibility is the order of the day. Business priorities can change intra-day and most development teams must be ready to respond to business needs on a daily basis.

Common Source Code - CCRB
In one organization we found that there was a common body of code that affected every project. We were able to implement formal change control and CM Planning. This involved a Monday morning meeting that went from 9:30am to 10:00am . We listed the proposed changes to the common base of code. Development managers only had a voice if they attended the change control meeting or they sent a representative. Change Control worked because there was a true business need for a formal process. CM Planning is valuable if and only if it has a clearly defined purpose.

Behaviorally Speaking
CM Planning can play an essential role in communicating expected (and desirable) behavior. A good CM Plan can be the contract that “Freezes” in place the Process Improvements that are essential to making your team a top software development organization.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment