Agile Software Configuration Management: Communications and Documentation

Agile software configuration management concepts and right-sizing the documentation on your projects are discussed.

When discussing any new concept, one of the biggest challenges is to establish a common terminology.  Agile SCM is no different.  Because it's a variation on an already existing discipline, terminology can become a barrier to discussion.  There are so many preconceived notions of terms such as "light-weight," "agile," "extreme," "process," and "structure" that using these terms without clarification or further discussion can occasionally lead to gross misunderstanding.

The term "Agile SCM" can elicit very different reactions based on someone's experience and perspectives.  There are those who believe that Agile SCM is negating many of the process benefits we've made over the past ten to fifteen years, resulting in lower quality software.

If you've thought that Agile SCM has declared war on discipline and control, you're not alone. Many in the CM community have reacted with these same feelings.  Do discipline and control lead to quality software?  Certainly agile methodologies are ultra-focused on quality through their use of concepts like test-driven design (TDD), refactoring, close customer collaboration, pair programming, etc. These methodologies are also ultra-focused on being simple, and "lean" - doing only that which "adds value" and removing that which does not. They are also about effective communication and knowledge sharing in a way that relies more on rapid feedback-cycles of face-to-face dialogue than on static knowledge captured in large formal documents that attempt to complete all the requirements before coding begins.

The Discipline of KISS (Keeping It Simple and Short)
Agility is partly about removing redundancy and complexity from all aspects of development: from designs, from requests and requirements, and even from and processes and tools. It is partly about separating niceties from necessities, forcing us to question what really is needed and remove the things we don't really need. Many times, there are gold-plated requirements, over-engineered systems, and overly complex or laborious tools and processes employed in many software development shops. These extraneous elements add complexity and/or redundancy that can create more friction than forward motion on development projects. The result is that they add little if any value to the bottom line - quality software.

The "Grand Illusion" of Control
"Control" is a term that gets thrown around a lot in the CM community. In many ways, Agile SCM is more about accepting and embracing change than preventing or controlling it. Agile methods acknowledge that "control" is merely an illusion, and a damaging one at that [1]. Discipline and predictability are quite different from control [2], and Agile SCM requires high discipline with short-term effective feedback. An Agile SCM solution is one aimed at helping developers make accurate code changes to the appropriate set of code while collecting data on changes as they happen.  Effective Agile SCM solutions then provide information to help users access that change data as well as enable consistent and predictable releasing of that code.

The Power of Tight-Looped Feedback
Many opponents of agility don't have an accurate understanding of its highly iterative nature and close-knit feedback loops at multiple levels of scale. Even those familiar with iterative development may not be familiar with iterations that are only a few weeks in length. The difference between 2-3 week iterations and 2-3 month iterations is tremendous.

The longer the period of time in between making a decision and being able to execute and validate/evaluate the results of that decision, the more we need to be sure of ourselves because rework is more costly. So more formality and more formal knowledge capture and signoff is necessary. When the period of time is contracted down to a couple of weeks, days or hours, rework is an order or magnitude less costly and decisions are more malleable and less needs to be "written in stone" because changing it isn't nearly so time and labor intensive.


About the author

About the author

About the author

CMCrossroads is a TechWell community.

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