The Next Generation of Agile Configuration Management

queries - Testcases missing, failed requirements.  
Communication is as much about getting information as it is about providing it.  If you can't go to an object and find out the things you need to about it, your interface needs improvement.  There's no room for poorly integrated management information in an agile environment.  If you need to know if a requirement passed it's tests in a build, you need to go to the requirement and ask that question. Similarly if you have a requirements sub-tree and you want to know if there are requirements not covered by testcases, you need to go to the sub-tree and ask that question.  If you need to find the build in which a
problem was fixed, you need to go to the problem and ask that question. If the tools don't let you do that, you'll have to learn some other more awkward way of getting that information.

Interactive CRBs, weekly/daily meeting support.
Your CM/ALM tools need to be able to support interactive CRBs, and weekly or daily team huddles.  It must provide up to the minute information that can be easily summarized, and zoomed into for detail.  If you need to have an expert in the room to do this, that's fine, as
long as the expert can do it in real time for you to run your meeting.  Better yet, your tools should be able to provide a list of objects that form the focus of your meetings, especially for CRBs.   And tracking meetings and action items from the meeting would be an additional benefit.

Priority-based feature/problem management.  
agile development is primarily feature/problem driven, rather than schedule driven.  Perhaps you pick features/problems from a pool, or perhaps they're assigned to you. Your tools must provide you with the capability to easily prioritize features and problems and to look at the features/problems which are candidates for or designated for the next iteration.  These must be priority sorted so that the view reflects what's most important.  Ideally, when your users log into the CM/ALM environment, or even their IDE environments, they can see a list of problems/features assigned to them or to their group pool, at a
click of a button.  Similarly they should be able to see their changes in progress.

Instant queries/reports.
This is important for meetings, but it's also important for communication. If queries and reports are less than instantaneous, they will fall into disuse to some degree.  The longer it takes, the less it will be used.  The less it is used, the poorer the communication of information.  And this extends to operations on the query results, such as navigating traceability links and zooming in for more information.  Metrics must be visible outside the tool, but when viewed inside the tool, it must be possible to look at them in more detail when necessary to help understand why a metric has fallen out of bounds.  If there are significant wait times to get these answers, your process improvement efforts will suffer and as a result, your agility.

Easy rebase/workspace synchronization.  
If it's a chore to rebase your workspace to reflect the latest changes, don't expect it to be done often.  The result will be development done against older environments, leading to less integration testing with other new features.  As well there will be additional workload on your developers when the time comes to check in their new development.

Easily Identify Changes for Each Iteration.  
An agile process is generally characterized by short iterative development cycles, or at least "release" cycles, where we use the word release loosely here.  When testing identifies problems with a new build, it's important to be able to rapidly compare it to the previous one so that the list of changes that went into the new iterations can be used as a starting point to