Agile Configuration Management Environments


Lean Identification and Reporting

Configuration identification is the set of all artifacts that describe one or more identifying characteristics of the end product and how to (re)produce it. Configuration audits and reviews become much more streamlined and efficient when the set of configuration identification artifacts is kept to the bare minimum to suit the requirements of the project.

  • Any required traceability tries to eliminate redundancy and rework by using fewer artifacts.  Detailed requirements or use-cases may serve double-duty as acceptance test cases. High-level requirements may exist in the form of feature/change requests and/or release notes (or be automatically generated using a template). Some end-user documents may even be used as use-cases or functional requirements documentation.
  • Reports (and status accounting) for management and customers are also streamlined to the minimum required set, and communicated regularly and visibly. The reports should be generated quickly and easily, and preferably automated by simple utilities that can search, sort, and format integration/build/test results or integration/release plans and their requests/tasks.

 Coordination and Automation

  • SCM tools and practices/processes cannot afford to hinder the agile development team or they won’t be used at all. Tools and processes need to be simple, pragmatic, and enhance communication and coordination or reduce rework. The value they add to the project must be clearly understood and appreciated. In particular, use of tracking systems and version control tools must be minimally invasive with the goal of being transparent. The agile team won’t readily tolerate an interruption of “flow” that comes from waiting for tools to collect data or complete lengthy operations.
  • Use of SCM patterns [1] such as private workspace, mainline, codeline policy, active development line, private system build, workspace update, task-level commit, integration build, and smoke test will help each developer seamlessly perform their development and SCM duties on a daily basis while keeping the codeline clean and safely integrated, and the team well coordinated with one another’s development efforts.
  • It turns out that integration and test are forms of communication and feedback between developers and their changes. Hence frequent and regular integration/test is critical for successful agile development! So is effective use of branching and merging:
  • Branching should be done sparingly, creating new codelines only when parallel maintenance and development is unavoidably required. When branches are created, a Mainline should be used to maintain a manageable branching structure.
  • Integration, build, and test activities are automated to the greatest extent feasible. Build tools/scripts, code structure, and network resources must be leveraged appropriately to minimize build times. One of the single biggest “drags” on development feedback cycle-time is the “friction” that comes from prohibitive build-times, or long testing-cycles that force development to either freeze or branch the code-base for significant periods of time while waiting for integration/build/test activities to complete.

Putting it All Together: Opening, Middle Game, and End Game

The bottom line is that, to promote and sustain agility, SCM processes and tools must eliminate bottlenecks in feedback cycles by:

  • Easing up on rigid front-end controls,
  • Coordinating and streamlining development changes and communication
  • Automating back-end integration/build/test activities, increasing their frequency, and incorporating them into daily development tasks


[1] Software Configuration Management Patterns: Effective Teamwork, Practical Integration, by Stephen P. Berczuk and Brad Appleton; Addison-Wesley, November 2002.

[2] Agile Software Development Ecosystems, by Alistair Cockburn and James Highsmith; Addison-Wesley, March 2002

[3] Agile Software Development: The People Factor, by Jim Highsmith and Alistair Cockburn; IEEE Computer: November 2001 (Vol. 31, No. 11), pp. 131-133

[4] Retiring Lifecycle Dinosaurs, by Jim Highsmith; Software Test and Quality Engineering Magazine (STQE), July/August 2000 (Vol. 2, No. 4)

[5] Software is not a Product, by Phillip Armour; Column “The Business of Software” Communications of the ACM August 2000 (Vol. 43, No. 8)

[6] What Is Agile Software Development?, by Jim Highsmith; Crosstalk – the Journal of Software Defense Engineering (special issue on Agile Software Development), Vol. 15, No. 10, pp. 4-9

[7]  The Agile Manifesto, also appearing in Chapter 1: Agile Practices, pp. 3-11 of Agile Software Development: Principles, Patterns, and Practices, by Robert C. Martin; Addison-Wesley, November 2002

[8]  The New Methodology, by Martin Fowler; created July 2000, revised April 2003; also published in abridged form as “Put your Process on a Diet”, Software Development Magazine; December 2000 (Vol. 8, No. 12)

[9] Agile Software Development: The Business of Innovation, by Jim Highsmith and Alistair Cockburn; IEEE Computer: September 2001 (Vol. 31, No. 9), pp. 120-122

[10] Software Engineering Body of Knowledge (SWEBoK), Chapter 7: Software Configuration Management, pp. 7.1-7.17; Version 1.00, May 2001

[11]Configuration Management Principles and Practices, by Anne Mette Jonassen Hass, Addison-Wesley, December 2002, Chapter 18, pp.207-224 and Appendix C: Agile SCM, pp. 343-348.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.