For many people, Agile software development congers up the thought of "undisciplined" software development. The reality is that using an Agile approach to its greatest benefit requires discipline in a variety of ways. None is more critical than the discipline of software configuration management. Agile teams are generally small, but their SCM needs are big.
Agility and SCM
The importance of discipline in software configuration management is clearly highlighted in my book Agile Software Development: Evaluating the Methods For Your Organization. A third of Chapter 12, "The Unstated Principle: Appropriate Processes and Tools," is dedicated to configuration management processes and tools. Why? Because the practices that are at the heart of Agility require them.
· Incremental delivery means that the team is regularly making changes to a released baseline.
· Welcoming change means that requirements are always in flux, and a requirement may be changed even after it has been implemented.
· Pair programming and collective code ownership mean that everyone needs to have access to all of the code all of the time, and collisions among changes are likely.
· Continuous integration means that the build process must be easy and bulletproof.
Let's look at each of these.
Incremental Delivery
The major defining feature of the Agile approach is an iterative development process that delivers the product for acceptance (and possibly for deployment) incrementally. The first increment of the product is delivered quite early in the project, and from that point forward, the project is extending and enhancing that first increment. A 9-month long Agile project is likely to be making between ten and twenty deliveries of software!
The Agile team must be able to carefully manage not just code, but also the content of each delivery to their customer. Such a project will push most simple code control tools to their limits. Most sophisticated CM tools would be a better fit for such an environment.
A tool is only as good as the team members' discipline in using it. Any Agile team must embrace clear expectations for the CM disciplines that will be followed, and each member must be dedicated to maintaining those disciplines. Starting with the right version of a code module for each development task; checking code out and in when appropriate; flagging modules that are build-ready; and many other disciplines are required.
Incremental delivery adds significant complexity to the development process. Good CM disciplines and tools are needed to meet the challenge.
Welcoming Change
An Agile project's requirements could change at any time. The flexibility that is implied by the word "agile" means that the project expects change and is tuned to allow it.
Each of the Agile methods places extensive focus on practices for managing requirements change. It isn’t called "change control" but they all do a respectable job of keeping the project on an even keel while welcoming changes to requirements. What may be less apparent is the degree to which such an environment of change can stress the team's software management practices. If the customer changes something that has not yet been implemented, it will not likely be a big deal. When the response to a new increment of software is "almost" the team must be able to isolate and correct what is lacking. But sometimes your customer will say, "You know that stuff you did two months ago? It's all gotta change." In those cases, the ability to distinguish what was coded for those stories from what was added since then will be critical to the team's ability to adapt to the change.
Welcoming change means welcoming project complexity. Good CM practices will allow you to manage that complexity.
Pair Programming and Collective Code Ownership
Not every Agile team employs these practices, but those that do must employ even greater care in how they manage their code. These two practices mean that code is not owned by anyone, as the whole team owns all of the code collectively. When there is no code ownership, anyone might be changing a particular module of code at any point in time.
Any Agile team that uses these practices must have appropriate mechanisms in place to either avoid collisions (when two people change the same code at the same time), or to deal with them in a controlled and rigorous way. This implies mature CM tools and discipline in how they are used. It also implies that team members collaborate with each other when a collision occurs to ensure that it is resolved appropriately. When an Agile team's practices provide the opportunity for people to step on each other’s work, good CM tools, along with collaboration and discipline are the only way to keep order.
Continuous Integration
Most Agile teams practice continuous (or at least daily) integration. With continuous integration, as each change or enhancement is complete, it is immediately integrated in to the product baseline and fully regression tested. If all tests pass, it becomes the new product baseline. With daily integration, all of the completed work for the day in integrated and tested overnight, so the team begins with a new product baseline each day.
These practices compound the difficulties described above under "incremental delivery". This is because now, instead of establishing a baseline every few weeks, we are establishing one every day, or even more often! The team's ability to identify and manage all of these baselines is key to their efficiency.
Continuous integration also presumes that a different person is doing the build each time. This will result in inconsistencies and problems due to individual variations unless the baseline-build-test process is fully automated. Even daily integration works best with a fully automated process. Every developer will welcome never having to "do the build". Just click a button and watch for the green light!
SCM on Agile Teams
Migrating from a traditional to a more Agile development process does not reduce the need for good SCM. In fact, mature SCM tools and disciplined SCM practices are absolutely necessary for any team to get the most out of their Agile process.
