Agile SCM

Also see Agile SCM Articles and ContinuousIntegration!

The Role of SCM in Agile Software Development

Often people think of configuration management and version control as process-heavy things that might get in the way of the "real work" of coding. For many projects, SCM does get in the way, and some organizations overcompensate and don't use the tools to help them because of a fear that a process is inherently limiting. Other organzations want control and have so much process around version control that they hurt themselves. The right amount of version control is appropriate in agile projects...

Often conflicts about software configuration management arise because of the difficulty of determining how much structure you need. Too little and chaos reigns, too much and the environment becomes stagnant...Highsmith also observes that "one of the reasons for this divide between process and practice is often the perception that an onerous process reduces the incentive to use any process." This reflects the reality that what matters is not your process as much as what people actually do.

[End Excerpt]

Agile software development methodologies are based on short cycles of iterative development. By developing software in an iterative and rapid fashion, a development team can put working software in the hands of the customer quickly to solicit feedback and refine the requirements for the software system under development.

Projects that employ an agile methodology need an SCM environment and process to support rapid, iterative development. In particular, these projects need to continuously integrate code. This means the project needs to build often, perhaps more than once a day. Projects that follow an agile methodology may need to use branching strategies to support frequent integration and concurrent development.

-- MichaelSayko? - 20 Dec 2002

I think Configuration Management is going to be critical "fulcrum" in leveraging a balanced and effective set of SCM processes and criteria for agile development methods. With such a large emphasis on lean and lightweight from the "agilists", CM on agile projects will need to be less intrusive/invasive (what Grady Booch would call low-friction) to allow agile projects to succeed while at the same time not being so minimal (due to overreaction) as to contribute to their failure.

Steve and I hope our book SCM Patterns (quoted above by MichaelSayko?) is a step in that direction. It's a bit more CM than many agile methods may appear to embrace (and certainly a LOT more for those shops that were entirely ignorant of CM), but its a good foot in the door to establishing some core SCM discipline among small development shops while still being low-friction, and (we hope) paving the way for some more formality applied in balance and moderation (like CCBs, which don't have to be as much red-tape as many developers from small-shops often assume the moment they hear the "CCB" acronym).

-- BradAppleton? - 06 Feb 2003

Brad gave a great and not at all scary theoretical overview of the AgileDevelopment concept. To add a tiny bit of "practical application of method":

The key is to understand (for any particular type of Agile development) the intimate relationship among requirements, model, documentation, code and test so that, when defining a unit of change, all of these are grouped together. Of course, it is always a good idea for the architects, designers, coders and testers to work together but we know that in the real world, this does not always happen. In the Agile world, this type of cooperation is mandated, and an easy way for CM to become a part of it is to have a CM representative participate in the design meetings.

-- CarildaThomas? - 07 Feb 2003

Also see Agile SCM Articles, and reflexions on agility!

Some other views on Agile SCM may be seen at:

• The April Issue of CMCrossRoads News is devoted to Agility and SCM
• Damon Poole's blog, Agile Software Development Thoughts
• Notes from birds-of-a-feather session on Agile SCM at XP/Agile Universe 2002
• An Appendix on Agile CM from the book Configuration Management Principles and Practice
  (See SCM Books)