ways of controlling and managing project work products using learned skills. Only when the needs of the project become more demanding and the tasks of controlling and managing project work products become noticeably less efficient, should automated tools be considered.
Working software over comprehensive documentation. The Agile project team is focused on Agile methods (e.g., pair programming, small releases, simple designs, refactoring, collective ownership, communications, commitment, etc.), and the suite of documents traditional teams are used to are not produced in favor of creating working software . Thus, the Agile SCM group is likewise focused on simplified control and management mechanisms to ensure the integrity of the working software .
Customer collaboration over contract negotiation. The Agile SCM group and the customer work together closely to actively participate in the overall planning strategy ( customer collaboration ).
Responding to change over following a plan. The Agile SCM group participates in strategic project and technical domain planning. In Agile software development, there may not be a CM plan. CM planning becomes an integral part of project planning, or the planning game ( Kent Beck ) , where continuous peer reviews, short iterations, and frequent project planning updates are the rule. The planning game is the boundary or the point of interaction between customers and developers ( responding to change ), specifying the responsibilities of both parties.
This is not the end of the story ¾ it’s really only the beginning. There are some very important things to remember about Agile SCM.
Agile SCM is not:
- A lightweight (or canned) version of traditional SCM approaches
- An approach that can be disassembled into pieces that can be applied piecemeal
- Measurable with irrelevant yardstick measurements
- A “silver bullet” (at least, not all the time)
Agile SCM is:
- A process that requires a lot of work
- A finely tuned and congruent process
- Vastly different from traditional SCM defined approaches
- In terms of the CMM, Agile SCM is stable and repeatable only through Level 3
WARNING, Agile SCM may cause:
- Dramatic improvements in engineering build and code management practices
- Positive cultural changes brought about by collaborative teamwork
- Positive changes in management as the organization becomes fluid¾that is, teams become empowered and managers stop being bosses to become coaches, mentors, and facilitators
- Management changes as projects are tightly measured by return on investment¾that is, doing the right thing well, not just doing the right thing
- Ownership changes as business people become responsible for project ROI on an iterative, incremental basis, constantly balancing cost, functionality, date, and quality to produce the greatest benefit
So, when is there too much SCM? Through careful collaboration and prudent planning by the project manager, project team, and SCM practitioner(s), the amount of SCM management and control for configuration items and work products can be gauged. Too much process and the team gets bogged down in trying to support practices that may not be adding real value to building products. Too much documentation and the team shifts its focus on preparing needless or unnecessary documents instead of producing working software .
And isn’t producing working software what software projects are supposed to do?
 Jim Highsmith, Agile Software Development Ecosystems , Addison Wesley Professional; 2002, ISBN: 0201760436
 Carnegie Mellon University, Software Engineering Institute, The Capability Maturity Model: Guidelines for Improving the Software Process , Addison-Wesley; 14 th printing, 2000, ISBN: 0201546647
 Laura Wingerd, Christopher Seiwald, High-level Best Practices in Software Configuration Management , presented at the Eighth International Workshop on Software Configuration Management, Brussels, July 1998
 Agile Alliance website, www.agilealliance.org/home
 Kent Beck, eXtreme Programming eXplained: Embrace Change , Addison-Wesley;