The Agile Difference for SCM


separationist assembly view in which we believe that the whole is exactly the sum of its parts!

  • We like being able to separately isolate the changes for each feature, fix, and enhancement so that we can back it out if it breaks, or propagate (merge or reintroduce) it to one or more other projects or project variants, or to a remote geographical development site.
  • We may prefer to be the ones doing the building/merging rather than having developers attempt it themselves (particularly for a remote site). This is sometimes called an integrator-pull model of integration, as opposed to a developer-push model of integration.
  • We may prefer that each development task be based off the latest stable development baseline instead of the off the latest and greatest state of the codeline, which might not be baselined.

Fortunately, there are ways to accomplish the same objectives without requiring the same old methods, though some compromise and trade-offs will be necessary. Few people like having to do multi-project, multi-variant, or multi-sited development and having to support them concurrently. If you really and truly can get away with having only 1-3 codelines, then challenge yourself to do so.  After, do whatever it takes to stay that way.

If you cannot avoid multi-project, multi-variant, or multi-site development, then:

  • Use the mainline pattern and maintain a codeline for each concurrent release that must be actively supported.
  • When possible, prefer an architectural solution to provide variant functionality (e.g., conditional compilation, run-time configuration, and principles and patterns of component-based, service-oriented, product-line architecture) instead of a branching solution.
  • If time zones aren’t too far apart and WAN/LAN performance isn’t an issue, have remote sites use the same central repository rather than a replicated/mirrored repository. If they are too far apart or if network performance is a problem, then use a site-specific integration branch and have it merged to (and updated from) the master integration branch as frequently as feasible.
  • You can still use daily or nightly (or more frequently) automated builds to verify the stability, consistency, and reproducibility of the development codeline. This also works for site-specific codelines.
  • Use continuous update with private-branches or task-branches to group together multiple tasks for the same overall feature/fix so that they can still be easily propagated to other codelines while at the same time staying reasonably up-to-date. Don’t forget to propagate fixes from the older (least evolved) codelines that need them to the more recently (and more evolved) codelines.
  • Use continuous staging to sync-up from multiple sites and/or multiple component teams.
  • Use task-level commit and task-based development (TLC and TBD) and appropriate pre-commit entry criteria to ensure that the tip of the codeline always corresponds to the current configuration (the last official baseline plus latest approved changes). Even if it’s not a baselined development configuration, if it is a true current configuration, then it’s good enough for development as long as it is still identifiable, correct, consistent, reproducible, and auditable.
  • Collaborate with the development team from the very beginning to ensure their builds are as clean, automated, and reproducible as possible, and that the codeline policy is enforced (preferably self-enforced).


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

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

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!