Applying Configuration Management to Agile Teams

the smaller chunks of work and higher rate of change. Typically this means that there are more incremental deliveries (both internal and external) with the implication of a greater need for automation, adjustments in branching and a stronger need for automated merging (more on this shortly).

Build... Continuously
In a traditional development methodology with longer release cycles, building the code does not typically start until the development phase and the build frequently may be weekly with some teams reducing this to several times a week or even nightly. In an agile methodology, builds should be continuous meaning as frequently as daily or nightly and more typically after every check-in (or promotion) into the integration stream.

Also, it is critical that a successful build occur in the private workspace with the local changes and the latest baseline of code from the parent or backing stream prior to promoting or checking in the code to the parent stream (note, this is a good practice irrespective of the development methodology used).

The ability to perform continuous builds also implies that you have both the tools and processes in place to manage this frequency. Implementing build tools such as CruiseControl or BuildForge (and there are many others) will help to achieve this. Another option is to script a build function upon check-in.

In addition, there is a strong need to understand the current build practice and adapt it with the build types that are needed (private, shared, integration, release) and levels of builds (component, product, etc.). This helps determine where the bottle-necks are - ergo, where the waste is.

Workspaces, Branching and Merging
In Agile, everyone should have their own workspace. There may be a need for shared workspaces if pair programming is being used. This way, the same two people can
share the workspace and changes therein. Most of the time they will work together, but sometimes they may need to work separately.

The number of branches that are needed depends on the Agile project and how it integrates with other projects. If the Agile project is small and independent of other projects, having a private workspace off of the mainline is not unreasonable. However, as the team gets larger, the need to have another layer of integration between personal workspace and main-line may be needed, but one should attempt to keep this a minimum if possible to reduce effort in integration.

With the rapid pace of Agile also comes the potential need for automated merging. Most CM tools today come with this feature so this should be a given in most cases. If not, consider upgrading. This becomes more of a need the larger the Agile project is or when more people must touch the same code modules.

CM Co-op environments
If your organization plans to deploy Agile in a big way, you need to have a CM Co-op
environment (tools, infrastructure, and processes) available to quickly bring Agile projects online and use CM immediately.

In a more traditional methodology, you have until the development phase to get the CM environment up and running. With an Agile methodology, the CM environment needs to be ready right after iteration planning which is much earlier than the development phase of a more traditional method.

This is where an organization should consider a CM Co-op service model to more quickly bring projects into using CM environment. This can be particularly advantageous when an organization is trying to bring several agile projects online within the same time period.

The CM Co-op eliminates the need for installing the CM tools, setting up the infrastructure, and establishing the