Breaking With Tradition

We do not usually associate the words "simple," "dynamic," or "agile" with software configuration management (SCM), but in many cases a simple, dynamic, and agile SCM process can greatly improve the productivity of a team. SCM gives you the ability to identify and control changes to your source code and reliably build a version of an application from a point in time. Agile SCM further enables you to integrate frequent changes, adapt to these changes, and get feedback on how they affect the quality of the system that you are building. To support feedback, agile SCM processes emphasize frequent integration and testing at all levels, in addition to the traditional SCM areas of build, release, and version management.

Common Mistakes
Software configuration management is definitely beneficial, so why are people often frustrated by it? The answer is that teams tend to misapply SCM in one of two ways: too much process or too little process. Ironically, one is often the consequence of the other.

With too little process, there's no mechanism in place to correct mistakes. The codeline quickly degrades, so rules and procedures are added to reduce risk. When too many are added, the workflow is disrupted instead of supported. Despite a sense of security, errors still make it past development and are discovered much later. Since the context for the error has been lost, it is more difficult and more expensive to fix. See the StickyNotes for a link to the article "The Illusion of Control" that explains how the attempt to gain control by adding rules often backfires.

Too little process is often a reaction to witnessing the perils of too much process. Teams avoid anything that looks like SCM and lose the coordination advantages that SCM provides. It appears that they are making progress, but they have no way to verify that the changes made in one place don't interfere with work elsewhere.

To establish an appropriately agile SCM process, you need to overcome your fears and adopt practices that fit your development process.

Agile SCM Practices
Practices To maintain a quality codeline and to be more productive, agile teams rely on communication, frequent integration, and the resulting feedback—using just the right amount of process. Some agile practices that you can use even in a non-agile environment are:

• Working on a single active development line
• Working in private workspaces
• Using continuous integration
• Performing frequent testing
• Deploying Frequently

Some of these practices cause worry among those who are used to more traditional approaches to SCM ("Don't you lose stability by committing changes so frequently?"). Agile SCM allows more errors to occur but reduces risk by catching and correcting them more quickly, before they can do harm. 

Active Development Line
Some teams allow developers to work on branches in an attempt to preserve the integrity of the main codeline. The branches cause deferred integration, which makes development more difficult since many problems surface during integration, long after they could have been detected. In contrast, an active development line is a single codeline to which every team member commits changes

For a single active development line, you need:

• A culture that encourages finegrained, frequent check-ins
• Optimistic locking
• The supporting practices of private workspaces, continuous integration, and frequent testing