Agile Configuration Management Environments

[article]
Summary:

How can software configuration management be compatible with agile software development? Aren’t the two diametrically opposed to one another? Sometimes it may seem that way. There is a commonly perceived tension between SCM and development agility that makes it difficult to achieve an effective yet precarious “equilibrium” between the two:

People often 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 organizations 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. [1]

What is Agility?

Cockburn and Highsmith [2] define Agility as “the ability to both create and respond to change in order to profit in a turbulent business environment.” They follow-up by asking, “What is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and maneuverability.” Agile development methods arose from a climate in which the business and technology worlds move at high speeds with high uncertainty and rapidly changing customer needs and priorities to survive in a turbulent and competitive market. The only way to survive in this environment is to become lean and nimble, capable of rapid response to change and churn.

Achieving Agility

Achieving this capability while avoiding unproductive thrashing of the project requires high quality communication and tight feedback loops between competent team members and with project stakeholders. This allows the project team to iteratively grow the product architecture and functionality despite ever-changing customer requirements and priorities. Responding quickly and effectively to change is easiest to do when you can minimize the following [3] 

  • Cost of knowledge-transfer between individuals
  • Amount of knowledge that must be captured in intermediate artifacts
  • Duration of time between making a project decision, and exploring its results to learn the consequences of implementing that decision

Achieving agility hinges upon reducing the time and cost of human learning [4] and its associated human activities of knowledge exploration, acquisition, transfer, and capture (and, ultimately, codification) [5]. This makes close collaboration and frequent iteration critical to the success of agile development.

Agile Development Characteristics

For this reason, agile methods focus upon the strengths of people and teams more than they do upon rigorous processes or detailed documentation. Processes don’t develop software. People do! Therefore the agile process must be molded and shaped to make the process serve its practitioners (not vice-versa) [6]. This gives rise to an agile world view based upon the set of agile values and principles put forth in the Agile Manifesto [7]. Projects employing the methods founded upon these principles and values share the following key characteristics:

  • Adaptive:  plans, designs, and processes are regularly tuned and adjusted to adapt to changing needs and requirements (as opposed to predictive methods that attempt to develop comprehensive and detailed plans/designs/requirements “up front”) [6][7][8]
  • Goal-driven:  focus on producing end-results (working functionality) in order of highest business value/priority [7]. “Agile approaches plan features, not tasks, as their first priority because features are what customers understand” [9]. (Contrast with being task-driven, document-driven, process-driven, or risk-driven)
  • Iterative:  short development cycles, frequent releases, regular feedback [1][7][8]
  • Lean:  simple design, streamlined processes, elimination of redundant information, and barely sufficient documentation and methodology [6][7][9]
  • Emergent behavior:  quality systems (requirements, architecture, and design) emerge from highly collaborative, self-organizing teams in close interaction with stakeholders [6][7][9]

Pages

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 Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

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

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

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09