Agile Configuration Management Environments

• 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]

SCM Versus Development (Great Walls of Ire) Various IEEE standards partition configuration management into at least four areas (with a fifth area recently acknowledged in [10]):

• Configuration Identification

• Configuration/Change Control

• Configuration Status Accounting and Reporting

• Configuration Audit and Review

• Build and Release Management

Many of these aspects of SCM have long been considered by developers to be overly formal, rigid, and bureaucratic. At the same time, many software configuration managers and SQA professionals often perceive developers as undisciplined or ignorant of SCM concerns, constantly compromising product quality or integrity in the name of schedule or development speed.The truth is that both sides are both right and wrong! The real problem is that they are on two different sides instead of on the same side. Many organizations segregate development responsibilities and SCM responsibilities almost exclusively to disparate people and teams in isolated activity-sequences of the development process lifecycle: development essentially delivers to SCM by “throwing it over the wall” to the next group down-stream in the lifecycle for integration, build, and test.This “wall” all too often forges a barrier to effective communication and collaboration between developers and SCM people: each of these two “cultures” becomes indifferent or resentful to the concerns of the other and the impact upon themselves and each other. The resulting organizational dysfunction creates a self-sustaining “vicious cycle” that grows increasingly more problematic and adversarial over time. Something must be done to break the cycle and bring both sides together! Agile Software Configuration Management (Agile SCM)

Effective software configuration management is crucial to the success of agile projects [11]. The key to understanding “agile” SCM is recognizing that in order to succeed in an agile environment without breaking agility, SCM processes and practices must embody the agile values and principles to achieve the characteristics of agile development. SCM is a “Whole Team” Responsibility First and foremost, SCM people and developers must work in close collaboration toward the shared goal of successfully meeting a project’s business and technical needs and requirements. Ideally, they should all be part of the same team. SCM should be a shared responsibility that is part of every team member’s day-to-day tasks and activities:

• Everyone is responsible for regularly integrating, building, and testing in their own private workspace [1] before committing their changes to the repository.

• People who know how to build the system and design the build scripts collaborate daily with the people who design the architecture of the system. Often they are the same set of people and/or rotate the responsibility across team members. Everyone understands and appreciates the needs of both development and SCM because they experience the needs and benefits of both every day.

• If the build breaks, the whole team takes ownership of getting it working again (usually starting with the person whose changes caused the “breakage”).

Responding to Change Versus Controlling it An agile project’s tolerance for change must accommodate the rate of change of the specific business environment as opposed to some preconceived notion of how much change is acceptable. This is because agile projects are driven by business value rather than by conformance to the plan: “if we accept the notion of constant change and turbulence, then plans are still useful as guides, but not as control mechanisms…because they tend to punish correct actions” [2]. Control is established by managing expectations with close communication and simple boundaries – “time