The Future of Agile Configuration Management: 2006 and Beyond


by an organization, the industry itself will do so. The key factors are the requirement for audit and the fact that directors and other responsible people can be imprisoned for signing a statement that later turns out to be false, particularly if there are catastrophic financial and/or life-threatening results.

It is as yet unclear what the implications of this are and how the audits will work in practice. What is certain is that the threat of imprisonment is concentrating the minds of a lot of people who wish "appropriate procedures" to be put in place.

While this will obviously affects the whole of CM, it is going to be particularly interesting to review the effects on agile initiatives. In a previous column [14] we reviewed agile methods, and the concern about them from the point of view of traceability. For example, how does a director know that there are no backdoors in the products produced by his or her company? Does it make a difference if the development team used XP and the requirements are only stored on index cards?!

This is going to be a huge area. Indeed, recently, there has been a rash of seminars announced on this subject as consultancies jockey for the privilege of educating worried directors and holding their hands through implementation and deployment.

The impact upon effective yet necessary CM for agile development will be very large indeed, and many are already starting to see and feel it. In CM terms we need to quickly and easily see the status of any change, version, request or build provided:

  • Task-Based Development will play an important role here too : Some kind of task-based scheme (see Austin Hastings article [4] on how Task-level commit (TLC) is one ingredient on the road to task-based development (TBD)) will be a key plug-point for integrating with (and tracing to) project management activities, estimates, requirements, tests, and verification/validation/auditing.
  • Real Tracking Tools - the fervor to resist automated project & change tracking tools in favor of index card will have to give way to the inevitable realities of mandated traceability. Cards may still be used as an effective means of engaging in dialogue and a tactile mechanism for gathering and enacting stories and scenarios. But even then they will need to be supplemented with automated electronic tools that connect a projects "tracking" database with that of the rest of the organization in order to perform effective portfolio management at the organizational level, as well as search, sort, query, report, and "refactor" issues across all projects or products in an overall program.
  • Dynamic Event-Based Traceability (such as that attempted by the SABRE project and DePaul University Requirements Engineering lab) will become more desirable as a means of automating much of the requirements traceability burden. Look for hand-crafted solutions to be scripted together initially (some might even make use of the new annotation and metadata features in J2SE 5.0 ), and then for commercial tool-support and/or open-source efforts a few years afterward.
  • SCM and Requirements Repository Integration/Unification - typically, source code version repositories are separate from the repositories used by requirements management tools such as DOORS, Requisite-Pro, and CaliberRM. This poses a significant enterprise integration and deployment/upgrade/support burden on organizations trying to integrate the two in order to facilitate traceability and change-tracking:
    • The Requirements Management tools typically have wonderful facilities for attaching and viewing meta-data and links and taking a container-based view of collections of items, while lacking considerably in areas of branching and merging and baselining when it comes to having to support multiple projects/variants/sites. The

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!