CM: THE NEXT GENERATION of Agile CM

to ensure traceability and reporting capabilities.  Ideally your CM tool should be a central focus of each "next iteration" meeting - whatever form or name it may take - and it should be capturing the results of those meetings, especially in terms of problem/activity prioritization and assignment, but also in terms of clarification.  This will lessen the red tape and ensure that everyone, including testers, will have their marching orders clearly defined for the next iteration.

Doing all of this allows you to capture your requirements as you go, and in a way that facilitates the work of your team.  Assigned problems/activities should appear on developer and tester to-do lists, and object-oriented behavior should be used to initiate (and trace) change based on those to-do list items.  At the same time, the entire product backlog is captured and is there for the product manager/owner to consider for the following iteration.

Agile CM Basics - Keeping Agile CM Simple
Assuming your CM tool can handle the basic components of Request, Problem and Activity/Task, the next thing to consider are the more traditional CM capabilities.

The most important one is change packaging.  At Neuma, we refer to change packages as Updates (see last month's article on terminology).  An Update is traced to the authorization items (i.e. the approved problems/activities) and collects all of the files to be modified in a single place.  The CM tool must facilitate the basic change operations.  For example it should:

• Allow you to specify a Product and a Stream and/or Iteration for your context
• Automatically show your to-do lists for that context
• Allow you to create an Update which is automatically tied to your context
• Only allow creation of an Update through an object-oriented Problem/Activity action, and must automatically trace to that item.
• Associate, by default, each check-out operation with your current Update (with a selection pick list of any other active Updates you have)
• Allow check-in of the entire Update as a single operation
• Allow peer review (delta report) of the entire Update in a single operation (both before and after check-in)
• Allow promotion/roll-back of the entire Update as a single operation
• Allow developers to quickly assess the contents of their workspace

If you have these capabilities, you will be saving your developers time.  CM will not be an overhead, but rather a productivity tool for them.  Of course this takes for granted that they can easily navigate the source tree, that the delta reports are easy to read and adjust, that to-do lists are readily accessible, and that there's no other interference (such as artificial requirements to keep source code changes out of the repository, to manually apply labels, to branch unnecessarily, etc.).  Take out any of the steps above and one of two things will happen:  you will lose traceability information that requires manual effort downstream (or even by the developer), or you will require manual, error-prone data entry, navigation or repetitive overhead by the developer and/or others in order to capture information properly.

When you attempt to create "Lean CM" by leaving out capabilities, you create less "Agile CM" by forcing overhead elsewhere.

Build Automation
Agile projects are often associated with continuous builds.  I'm fine with Agile projects having nightly builds, or twice a day builds. But whatever you choose, the key is automation.  Build automation means first and foremost that, when it's time to do a build, it basically requires only a single button or trigger.  Build automation can mean different things to different people.  For example, does it mean:

• No manually maintained "make" (or "ant", etc.) files.
• Automatic selection of what