The Next Generation of Agile Configuration Management

identify the source of the problems.  It's not good enough to identify a list of files that have changed.  Often in an iteration, a dozen or two changes may involve several dozen file changes.  If you can easily scan a list of 15 changes and pick out
two or three potential problem sources, you'll streamline your process of correcting the iteration.

Branchless Promotions.
If you are managing promotions using branches, a promotion will mean a merge operation is necessary.  This is a pessimistic algorithm that assumes all changes are promoted in random order.  For the most part, changes will flow through the system in the same order as their original creation (i.e. completion).  It is the exception that requires rearranging the order of changes.  Yet promotion-based branching incurs the merge penalty always. Time to rethink this strategy to eliminate extra promotion branches so that merging occurs only when required.  Another bad side effect of a branch-based promotion model is that it is a big deal to introduce a new promotion level, so there is a lot of reluctance, even if it is necessary.  In agile CM, this leads to not improving the process in the name of keeping things agile.  Promotion should occur through promotion of changes, not through merging into a new branch.  The tool should be able to look at the change state and determine the appropriate context view and/or baseline/configuration based on these states.

Automated Build for SI and Designers  
This is a big topic and is usually a central topic for agile CM. Designers need to be able to do their own builds and testing.  And all building must be automated.  It's no good if the designer built it one way and it worked, but the System Integration team can't get it to
build.  If your nightly builds are not automated yet, make that a priority task.  Do what you need so that your builds will run automatically every night. Perhaps one that has all the "checked in" changes, and another more stable one that has all the "selected/approved" changes.  When this is done, make sure that the developers can use the same build automation capabilities that the nightly builds use.  That will allow them to test what is going to be built and integrated before your nightly build.  That will mean fewer errors in system builds.

Branch per stream.
In an agile environment, it is important to be able to rapidly iterate, yet to work towards releases which are longer term than an iteration. The traditional main trunk model works well for a single release, but when subsequent releases appear, the support structure is compromised.  As well, the strategy for working on future releases is typically complicated to the point that only developers themselves are aware of future release work until the future release is promoted to the main trunk.  Instead, it is recommended that a main branch exist per release stream.  That way, work may proceed on any stream at any time, allowing support, advanced work or normal development without having to change the process or artificially schedule dates for the main branch reflecting a new release.  If you really need "leapfrog" check-in capability, whereby parallel teams are working on the same release but using overlapping iterations, consider two parallel streams per release, which eventually will merge into one.

What Else Can You Do
There are many things you can do beyond the above checklist. First of all, look at the tools you are currently using.  Make sure the architecture of those tools will take you well into the next generation.  Odds are that if your company is successful with it's current project, the results of that project will be expanded upon for many years to come.  You don't want your tools failing you along the way.

Look at how you handle parallel checkouts for short term parallelism.  Many of the successful projects, including