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 )
- 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 . 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  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” . Control is established by managing expectations with close communication and simple boundaries – “time 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”.