Agile Configuration Management Environments

boxes” in the form of iterations. After each iteration, expectations are (re)set and priorities are adjusted for the next iteration.So configuration and change control procedures need to embrace rather than prevent change. Perhaps change control board (CCB) meetings should even be called “change planning meetings” to avoid the stigma of trying to control change rather than manage it.

• Such meetings occur at the beginning of each iteration to identify its feature content according to customers’ latest priorities.

• The meetings need to be short and effective and include the business customer in the collaborative decision making process.

Authorization for developers to make changes needs to be instantaneous upon approval:

• Once a developer has signed up for a task, they should not have to wait to begin checking items out of the version control repository.

• And when the development team finds a bug that breaks the build or a fails a required test, they must be able to effect the repair without having to wait any noticeable period of time to receive “authorization”.

Lean Identification and Reporting Configuration identification is the set of all artifacts that describe one or more identifying characteristics of the end product and how to (re)produce it. Configuration audits and reviews become much more streamlined and efficient when the set of configuration identification artifacts is kept to the bare minimum to suit the requirements of the project.

• Any required traceability tries to eliminate redundancy and rework by using fewer artifacts: Detailed requirements or use-cases may serve double-duty as acceptance test-cases; High-level requirements may exist in the form of feature/change requests and/or release notes (or be automatically generated using a template); Some end-user documents may even be used as use-cases or functional requirements documentation.

• Reports (and status accounting) for management and customers are also streamlined to the minimum required set, and communicated regularly and visibly. The reports should be generated quickly and easily, and preferably automated by simple utilities that can search, sort, and format integration/build/test results or integration/release plans and their requests/tasks.

Coordination and Automation

• SCM tools and practices/processes cannot afford to hinder the agile development team or they won’t be used at all. Tools and processes need to be simple, pragmatic, and enhance communication and coordination or reduce rework. The value they add to the project must be clearly understood and appreciated. In particular, use of tracking systems and version control tools must be minimally invasive with the goal of being transparent. The agile team won’t readily tolerate an interruption of “flow” that comes from waiting for tools to collect data or complete lengthy operations.

• Use of SCM patterns [1] such as Private Workspace, Mainline, Codeline Policy, Active Development Line, Private System Build, Workspace Update, Task-level Commit, Integration Build, and Smoke Test will help each developer seamlessly perform their development and SCM duties on a daily basis while keeping the codeline clean and safely integrated, and the team well coordinated with one another’s development efforts.

• It turns out that integration and test are forms of communication and feedback between developers and their changes. Hence frequent and regular integration/test is critical for successful agile development! So is effective use of branching and merging:

  • Branching should be done sparingly, creating new codelines only when parallel maintenance and development is unavoidably required. When branches are created, a Mainline should be used to maintain a manageable branching structure.

• Integration, build, and test activities are automated to the greatest extent feasible. Build tools/scripts, code structure, and network resources must be leveraged appropriately to minimize build times. One of the single biggest “drags” on development feedback cycle-time is the “friction” that