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. In reality, though, Agility provides some great practices that can be adopted by any organization to ensure that the inevitable changes are well managed.
Change Control versus 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. 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 this 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 then altered to accommodate the changes. The value of this cannot be underestimated. All of the following parts of Agile change management are dependent 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 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 the team's plan, their status is tracked just as rigorously as any other work. All of the activities that must take place to complete the change are identified and they must be complete before the change can be called complete.
This is one of the more insidious problems with changes. They often fly under the radar, being implemented partially, and with important parts left un-done. The testing may be haphazard, the code may be badly managed, or the user guide may be un-touched. Perhaps the change is made, but the requirements spec or design does not reflect it. In an Agile project, whatever is needed to call a requirement done is also needed for every change. A change is a requirement: a new one!
· Customer acceptance:Just as each requirement is subject to customer acceptance, each change must be as well. An Agile project does not distinguish between an original requirement and one that was introduced as a change. Therefore, all changes are subject to customer acceptance in the same way as each original requirement was.
Embracing Managed Change
The key to customer satisfaction is delivering what you promised to deliver. Any change that makes it through the change control process must be delivered to the customer as promised and with appropriate quality and integrity to what was requested.
The Agile method gives us great guidance on how to manage change once it has been approved. The essence of what the Agile methods teach is that a change is no different than any original requirement. We should take changes as seriously as we take any requirement and then manage them to completion, just as we do with any other requirements our customer has.
Change management is requirements management. When we understand this truth, the rest becomes easy!
