into the status of a project and allow them to contribute to the project where appropriate.
We value transparency and traceability that is maintained by the tools without overburdening the practitioners
Responding to Change over Following a Plan
SCM is about facilitating change, not preventing it. Use SCM policies and structures that allow your development team to progress at an appropriately rapid pace, but without losing control. Don't attempt too rigid a process or procedure. In conjunction with the first section on the importance of individuals, don't legislate for every last scenario in your process (all possible exceptions), but instead allow suitable experienced and trained individuals to make decisions in accordance with sound SCM principles.
The full list is at: agilemanifesto.org/principles.html
We have selected and adapted those that we consider the most relevant.
- Our highest priority is to satisfy the customer by maintaining the integrity of the software throughout its lifecycle, and making early and continuous delivery easy and simple to achieve.
- We welcome changing requirements because we can manage and control them in a light-weight, but consistent, way to harness change for the customer's competitive advantage.
- Change and configuration management are the responsibility of everyone involved in the project from business people to developers. SCM people must work with the rest of the team on a daily basis.
- Give individuals appropriate tools and environments to perform effective configuration management throughout the lifecycle.
- While agile processes encourage conveying information face-to-face, SCM requirements lead to some level of easily recording, tracking, and managing change to that information, preferring automation to manual processes.
- Working software is the primary measure of progress (not SCM metrics!).
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to (SCM) processes and systems enhances agility.
- Simplicity - the art of maximizing the amount of work not done - is essential.
- The best architectures, requirements, designs and SCM processes emerge from self-organizing teams with SCM responsibilities devolved.
- At regular intervals, the team reflects on how to become more effective in their SCM processes and procedures, then tunes and adjusts its behavior accordingly. This includes taking incorporating ideas from Lean thinking, Theory of Constraints and other such initiatives.
Who are the Customers of SCM?
SCM is a foundation stone of development processes and underpins many aspects of software development. SCM is also an enabler of other processes and procedures. Thus the customers or stakeholders of SCM range from developers to QA, project management, release engineers, potentially auditors, and indirectly the end customers/business users.
Orderly flow of change & evolution
SCM seeks to control change and we just need to make sure that this is adapted to consider the flow of change and ultimately the evolution of the system.
Systems that do not consider their evolution tend to become brittle and fragile - resistant to change. Activities such as refactoring can seem like unnecessary overheads, and yet their long term worth has been proven to many. Software must evolve gracefully, which requires supporting practices such as unit and acceptance test frameworks. Do your SCM processes have equivalent frameworks so that process can evolve in a well supported manner?
Repeatability, Reproducibility, Traceability
Fundamental watchwords of SCM, and yet how are they achieved? If the effort is too high, then they become merely theoretical - "Yes I could reproduce the systems as released, but it is too much hassle and is it worth it?!". This re-iterates the importance of appropriate automation (with unit tests or the equivalent), to ensure that systems can be advanced forwards or rolled backwards