Moving Change Control Into Iteration Planning
In a traditional development methodology, change control meetings are used to review and manage change. It is needed because the project is long enough that it has passed a requirements baseline phase and changes must now be managed. Because agile works in short iterations,
Change control is not needed and becomes imbedded in the iteration planning session. Of course, changes can get identified at any time and should be captured. However, the changes should get discussed during the next iteration planning session and not within iteration of work. Keep in mind there are times that a change does stop the iteration due to the nature of the change, but typically this is rare.
A CM professional can support development in both a traditional methodology and an agile methodology at the same time. On the agile projects, the CM professionals (particularly build and release engineers) should be invited to the daily stand-up meetings to ensure they hear of any CM-related problems without delay for quicker resolution.
Since daily stand-ups typically last no more than 15 minutes, this is not an unreasonable burden to the CM professional and helps them understand the context of the work at hand. Note, if the daily stand-up meetings last longer than 15 minutes, then it is probably breaking an agile rule and should be investigated.
If the build process is automated or well scripted, the CM role may also be shared by the development folks. In general, if it is the final build of the iteration (which always has the possibility of becoming the release build), then the CM professional should be involved. The CM professional should continue to be the person to migrate the built code to the next level to ensure integrity.
Adjusting CM metrics to identify waste
CM metrics can be a valuable part of any methodology, especially when they are focused on measuring waste which is often a key component of agile related metrics. Introducing the notion of waste from lean methods can help. This focuses on over-production, wait-time, transportation, processing, inventory, motion, and defects as introduced by Taiichi Ohno for manufacturing, then translated by Mary Poppendieck for software development.
Examples of CM metrics that can help an agile project are:
· Compare the stories or requirements that were prioritized for the release versus what was delivered (inventory or requirements).
· Identify the additional changes made not identified in the value stream (over-production or extra features).
· Capture time spent on recovery from broken builds (defects). Broken builds are outages and should be measured.
· Identify the number of builds that occurred vs. what was used further down the migration path (extra processing). This determines what the downstream processes can actually handle.
CM is critical to the success of all software development methodologies. The CM principles ensure the integrity of the product under development. CM may be implemented differently, though, as long as the CM principles remain intact. When moving from a more traditional methodology to agile, consider the importance of adjusting the CM processes to meet the pace of agile development and ensure the integrity of the value stream.
Focusing on implementing CM to best support shorter releases, continuous build, workspaces, branching and merging, automation, CM roles, and CM metrics is a way to support Agile and derive the benefits therein.
1. Software Configuration Management Implementation Roadmap , Chapter 1 section 2.1, by Mario Moreira, Wiley Publishing, June 04.
2. Lean-based Metrics for Agile CM Environment , by Robert Cowham, Brad Appleton, and Steve Berczuk, CM Crossroad CM Journal, March 2007
Lean Development Principles for Branching and Merging , by Robert Cowham, Brad Appleton, and Steve Berczuk, CM Crossroad CM Journal, July 2007
3. "Principals of Leaning Thinking" by Mary Poppendieck, Poppendieck LLC, 2002