The Next Generation of Agile Configuration Management

to have the necessary information at their finger tips to make good decisions.  If you can't trace easily from changes to features and from features to testing, this will not only slow down your process, but will necessarily make the traceability data less useful, less used, and hence lower quality.  Your processes simply cannot be sufficiently agile if your data is difficult to get to or to relate to other data. 

High Quality Data - Picking up data from context.  
High quality data is a result of having good forms with well-defined set of options.  But more than that, data has to be populated from context to minimize user data errors and to simplify and speed up user interaction.  If a user is working on a particular development stream of a particular product, that information should automatically be populated in any changes, problems, features, etc. that the user adds.  If a new change is started by clicking on a problem to fix it, the problem should automatically be traced to the change.

Labels Can Mean Trouble
If you need to manually label things, you've introduced unnecessary administration into your process.  You should be able to completely define and organize changes, baselines, build records, branches, etc. without having to create labels.  Creating a label is a short cut for an inadequate process/tool,  or a workaround for an overloaded capability.  For example, if I check out a file against a change, the branching (if necessary) should look after itself based on the change.  No need to apply labels.  A common mistake of many CM tools is to overuse branching - for promotion, for parallel development streams,
for release identification, etc.  Because of this, a branch does not imply what it could and so labels are introduced to discriminate the overloading of the branching concept.

Reduce dependence on version codes at the user interface.
Developers, and even CM managers should rarely have to look at version codes.  If they do, then the tool is not doing a good enough job in specifying the context and user interaction, or the tool makes specifying the context too much of a chore.  Version codes are fine for looking back at what was done in history.  But the user interface of a modern CM tool should be change focused, not version focused.

Easy rollback of changes.
Any agile development shop is going to have to pull changes that upset the stability of the product.  This should be as easy as rolling back the status of the change, if there are no higher promoted versions in the development stream.  If there are, the tool should let you know and leave you with the decision as to whether to roll back later changes as well, or to yank the change from the stream.  Both of these options must also be easy to do.

Change-based CM - One step check-in, one step promotion, one step delta, one-step propagate/yank.  
If you have to type in the reasons for each file revision you check out, or check in each file separately, do delta reports on a file-by-file basis, etc.,  you're process is a lot more tedious than it should be.  This will increase the reluctance to make and deal with
changes and will subtlety affect your process and your product quality.

Code in Repository.
One of the keys to agile development is knowing what's happening.  The CM repository needs to be a communication tool.  If you can't put you're code change in the repository when you're done your "unit" testing, only you know it's state, and others have to work from an older state of the corresponding files.  This complicates everyone's work, forcing additional parallel changes and merge/test cycles.  Make sure your process will allow developers to put code into the repository when it's ready, not when someone else is.

Object-oriented