traditional SCM but seeks to achieve the same results in perhaps a slightly different manner while remaining true to the basic principles of SCM. So it builds upon traditional SCM and still contains the traditional SCM non-development activities of configuration planning, identification, control, status-accounting, audit & review, build & release management, and the corresponding process for managing those activities.
Agile SCM does however inject the agile mind-set (and some would say paradigm-shift) into the discipline of CM. With that, comes an emphasis on flow and throughput of the project value-stream, and operating in service to that and to those who create value. Sometimes this has led to the slogan " Add nothing but value; remove nothing but waste! " when it comes to any from of process change or improvement in a Lean/Agile environment.
One way in which the "mind-set" can manifest itself in SCM is in emphasizing "flow" more than "discrete events" (e.g., rigid baselines, and authorization/access controls), and treating the integrated "whole" as greater than the sum of its separately assembled parts. This can be difficult for many to adopt, particularly when it comes to practices like continuous integration and test-driven development using fine-grained tasks and many commits and integrations during the lifetime of the complete implementation of a requested feature, fix or enhancement.
The agilemanifesto.org states the following.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We propose some equivalents or alternatives that add value to SCM.
Individuals and Interactions suitably supported by Processes and Tools
SCM processes and tools should support the way that you work, not the other way around. Often, the reason behind frustrating SCM processes is trying to impose an overly-rigid process on a team, or attempting to use a tool that imposes a process into an organization that is not what the organization needs. SCM must be done in service to the flow of the value-stream and those who create value. It must achieve goals like repeatibility, reproducibility and even traceability without compromising flow as a result.
One view of agile methods is that it is a license to hack and requires less discipline than traditional methods. In fact the reverse is true - agile methods typically require greater discipline and skills than traditional methods. A key tenet of Lean methods is that in order to "move fast" you can't afford errors and problems and thus need to be rigorous.
Applying this to SCM suggests that better understanding of SCM principles and tool usage by individuals and encouraging them, or making it easier, to do the right thing, is better than enforcing the process and absolutely forbidding the wrong thing.
Working Software and CM Processes over Comprehensive Documentation
CM supports the production of working software, but the challenge is to automate and ensure that appropriate processes are used that do not require huge process documentation.
Applying this also to the system being produced, we seek to automate as much as possible the production of supporting documentation (such as traceability reports). Information should not be repeated, and there should be a single master version.
Customer Collaboration over Contract Negotiation
SCM can facilitate communication and interaction among stakeholders and help manage expectations. The appropriate tools and processes can provide customers with visibility