CM: THE NEXT GENERATION of Agile CM

• goes into the build
• Tracking the difference between what is in the repository and what is to be built
• Generation of builds at different test levels
• Reporting errors back through an email or other alerting mechanism
• Automatic record keeping of the build content (i.e. how to reproduce it)
• Ability to generate builds for different variants and platforms
• Automatic sanity testing of the build
• Automatic build labeling, both in the repository and in the executables.
• Automatic generation of a list of updates, problems fixed, features addressed, etc.

I'm sure you can add to this list, and that you'll question some of these.  What is not so important is that the build starts automatically each day or whenever a new Update is checked in.  What is important is that, given the right parameters (e.g. Product, Stream, Promotion Level), everything else can be completed without human intervention.  Some might argue:  But what about sanity testing - that's not building?  Others would respond:  Why is seeing if an Update compiles more important than seeing if the Update "breaks the build"?

The next step is to give the developer the exact same automation capability (except, perhaps, without registering the build content in the CM repository).  If the same process is followed, and even sanity testing completed, we'll have a lot more confidence in the Update.

Going the Extra Mile to Stay Agile
Once the basics are in place, there are a number of extra capabilities that help to make CM Agile.  These are things that help eliminate the overhead while keeping the process where you want it.  A few of these are detailed below.  But making a process Agile is a continuous improvement process.

1. Requirements Tracking = Project Management
Traditional CM has Requirements Tracking as well as Project Management.  Requirements are requirements, project plans are project plans.  In Agile CM, these are not separate artifacts, nor separate processes.  Your requirements are being gathered in terms of activities.  You don't have two separate departments or managers - one for requirements and one for activities.  Your product manager/owner is the project manager.   What's different is that there is no schedule to lay out.  Instead, it's a priority based project management.  The highest priority items are addressed next.  A loose bar is drawn to identify what's in the next iteration, but it's really driven by what's done by the next iteration meeting.  Assignment of activities to development team members is still a task to be done in Agile because it's important for those with the most knowledge in an area to address change in those areas.

2. Allowing Multiple Updates Per Activity/Feature
Agile requires frequent iterations.  Because of this, there are often activities which are not quite completed at the end of an iteration.  In an ideal Agile environment, the mostly completed change is good enough to make it into the iteration, as long as there are no negative consequences, and there is value to adding it. If the tools aren't Agile, there may be an artificial tendency to either delay the change until the next iteration, or to redefine the task so that it matches what has been completed.  This makes the Agile, less Agile - it requires additional overhead to deal with a common problem.

Sometimes, it's best to implement a feature across multiple iterations so that the initial hooks can first be put in place, or so that it may be implemented in an upward compatible manner.  Whatever the reason, Agile CM must allow implementation of a feature through more than one Update.  The Update itself is a container for each Change that can