Applying Configuration Management to Agile Teams

processes. Instead, all that needs to occur is either setting up a repository following the established CM process or setting up a project branch within an existing repository.

Automate...
Simply put, CM for Agile requires more automation. Agile implies that the project team is developing product earlier and faster than the traditional methodology. Manual processes start to become bottlenecks to the progress that Agile can provide. Moving to more automated solutions removes bottlenecks and allows the team to focus more on development.

Of course, having automation within any methodology is beneficial, but for Agile it becomes necessary. Some examples previously discussed are build automation (for continuous builds) and merge automation. In addition, unit test automation and integration test automation can be added. Automating other types of testing is also beneficial (e.g., regression testing, performance testing, etc.) but outside of the realm of CM.

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.

Role
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 vs. 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.

Summary
CM is critical