The Next Generation of Agile Configuration Management

our own, rarely need to do parallel checkouts. Or if so, they are done in an informal fashion (i.e. get the code make the changes, reconcile on checkin).  Why?  Well, for us, several factors come into play.  

• We check our code back in as soon as it's ready
• Our design architecture allows us to focus most of our overlap on very simple changes which can be turned around quickly. 

• File ownership allows small groups to take responsibility for specific areas of the system.  But we still do need parallel checkouts. 

Fortunately our tool allows short term parallel checkouts without the need for branching.  The change record contains the same information as provided by a branch, and the CM+ tool allows us the option of recording or not recording parallel checkouts.  At check-in time, we are informed if there have been any changes since the checkout operation and, if so, a reconcile operation for the change being checked in is initiated.

There's no real value to having a couple of extra branches to show the history of the past three days work. As long as the two parallel changes make it into the build and the change deltas clearly show the changes independently, I'm happy. In fact, often you'll find branching for short term parallel changes only confuses the branch history.  Some tools even have ways of purging such branches to clean up the history. All this adds to the complexity. So why is branching done for short term parallel changes?  To provide visibility of the changes.  Your CM tool should provide this visibility without forcing you to complicate your branching architecture.

Tools must have a net payback for all users so as to encourage their continued usage.  If your users currently have to collect all of the files and do a delta report on them and then email that report around, that few extra minutes of work will add up over the course of several hundred changes.  Your tool should allow collaborative reviews from a single change identifier using a single click or two. If merging a change from one stream into
another (we call this Change Propagation) is difficult because the user first has to go through a long process of figuring out which files need to be merged and what the merge ancestors are for each merge, what will happen?  Any process requiring a merge will be strongly discouraged. If users have to create configuration view specifications to ensure that they can see the appropriate versions of their files, there will be loss of productivity and manual errors causing frustration.  It all comes back to ensuring that the tools you select will support your agile processes.

agile CM Requires Good Software Architecture
If you think that you can ignore your software architecture and still have an agile CM process, think again.  I've seen countless architectures where a handful of files are bottlenecks to the whole development process.  The same file needs to be changed by virtually everyone.  A single file is stretching the limits of your compiler or version control tool.  Introducing product variations is causing nightmares in the software.  Here are three key things that all projects can do to simplify their lives.

Minimize contention on files.  
Files have high levels of contention because they were designed to have high levels of contention.  If I have to put a change number in a single file every time I make a change, I'll expect a lot of contention.  If instead, all I have to do is call a routine with my change number, the contention disappears.  Same functionality, no contention. Most files which have a high contention on them can be dealt with in this manner.  Whether it's a change number, a message code, or even a function.  Replace the one-file policy with a distributed, less contentious one.  You'll also find that your version numbers for