A key part of planning configuration management for our projects is determining how we will manage change. After all, "change happens", and any good configuration manager is concerned with how it is managed.
Unfortunately, more often than not, our processes focus more on controlling change than on managing it! That is, we put a lot of effort into trying to keep change from happening, and relatively less effort into ensuring that when (not if, but when) change happens, we manage it effectively.
In our last article, we discussed how the Agile methods "Welcome Change". If you don't use an Agile approach, you may be tempted to think that it has nothing to offer you. But in reality, Agility provides some great practices that can be adopted by any organization to ensure that the inevitable changes are well managed.
Change "Control" vs. Change "Management"
First, let's define terms. What is the difference between Change Control and Change Management?
Change Control is all about critically evaluating each suggested change to ensure that it is the "right" thing to do. It usually involves authority being vested in an individual or a board to make decisions about changes. And in most cases, the intent is to minimize change. Change control is the mechanism that many projects put into place to try to avoid the disruptive effects of change.
Change Management on the other hand is mainly about what we do after a change has been approved. For those changes that we cannot avoid, how do we make sure that all of the things that should happen do happen? It helps us to ensure that the biggest potential disruptions of change (mistakes and unnecessary rework) are indeed avoided.
The Agile approach gives a virtual pass on Change Control. What the Customer wants, the Customer gets. This makes Change Management that much more important! When Change is expected to be a regular feature of a project, the mechanisms to manage it are paramount!
Managing Change Without Controlling It
So, how do the Agile methods manage change without controlling it?
Communication - Agile Change Management starts with communication. At the end of each iteration of development, all of the players on the project engage in a workshop where they discuss all changes that have come up since they last met. Since Agile iterations are only a few weeks long, this discussion is happening regularly!
The development team estimates each change, the Customer prioritizes the changes against the remaining work, and they collaborate to determine how to work the changes into the existing project plan.
The important part of this workshop is that everyone who is involved with the project provides input and is fully aware of the status of every change. Communication and collaboration are hallmarks of Agility, and that is what makes the Agile Change Management processes work so well!
Change Plan - As mentioned above, the result of the workshop is that the changes become a part of the project plan. They are not treated as "extra" work that the technical team is expected to add to their already overflowing plate. The technical team's estimates are taken at face value, and the plan is altered to accommodate the changes.
The value of this cannot be underestimated! All of the following parts of Agile Change Management are dependant on the fact that changes are treated no differently than what had been the original requirements!
Change Activities - An Agile team will have defined "Done" for themselves. That is, they will have agreed among themselves what it means for a chunk of development work to be complete. This will include not only coding, but also testing, and whatever else has to be done before the work is considered to be "done".
Because changes are integrated into the team's plan, these same standards are applied to changes just as they are to any other work. This avoids the all-too-common problem of changes causing problems because the process the team employs to make changes is less rigorous than their "normal" processes.
Tracking Changes - Again, because the changes are integrated into