"Agile" Change Management: From First Principles to Best Practices

of tools. Their physical limitations force developers and customers to keep things short and simple, and physically associate a request, its corresponding requirements, and its tests with the same physical artifact (in XP, the customer acceptance tests are the detailed requirements). Scrum and other agile methods appear to be less insistent upon the use of index cards, and less resistant to the use of tools (such as spreadsheets or change/request tracking systems).

Most experienced change and configuration managers would gasp at the seeming low-tech inefficiency of index cards as means to track and report conformance and status. At the same time, it is hard to combat the efficacy of index cards to engage customers in a more participative and collaborative dialogue for eliciting requirements, and drawing simple diagrams - apparently, the physicality and tactile experience of the cards is simply more inviting and lets the customer do the writing instead of relying upon a single input-controlling "scribe." (Some have suggested "pair writing" could be done between a developer and a customer in the same fashion that pair programming is done during implementation.)

Even if index cards are used as the medium for initial capture of requests and requirements, many (if not most) change and configuration managers will want to subsequently transfer this information into a spreadsheet or a tracking system for fast and easy reporting, querying, searching, sorting, as well as for real-time dissemination across the project's organization and stakeholder-sites (not to mention affording more efficient and reliable storage, record retention, archival, and retrieval/recovery). Keeping "stories" in a tool also lets you apply a simple workflow see how the work is progressing.

Several "agilists" would argue that such a tool "rails against" the mandate of simplicity. To be certain, many have gone overboard with defining and enforcing process through a tool - we highly recommend against that since it often results in drastically increased administration overhead, drastically decreased face-to-face communication, and hence very low agility. On the other hand, many have had bad experiences with tools used to enforce too much process. We believe this, combined with bad experiences from misapplied CMM level-climbing attempts, is responsible for much of the agile community's backlash against the use of more sophisticated but useful tools and processes.

The relentless focus on keeping things as simple as possible, and on face-to-face interaction over face-to-machine interaction still provides sound guidelines and important reminders when adopting processes and tools. With the "right" amount of process using a simple and "smart" tool, agile projects will find increased productivity and better coordination. The bottom line is really to do what you know works for you, and keep it as simple as possible, applying the principles of lean development [8] every step of the way.

Recap  

Change management is concerned with controlling and tracking changes to project and product scope and ensuring conformance to customer expectations. Agile change management is concerned with increasing the ability of the project to be responsive to requests for change and to quickly implement accepted change requests. This requires minimizing: the cost of effective knowledge transfer, the amount of knowledge captured in intermediate artifacts, and the time between making a decision and learning the effects of its result. The key success factors of agile change management are the use of iterative and incremental development with short feedback cycles, and close collaboration with frequent face-to-face interaction between developers and customers.

Sometimes the customer base is diverse and/or dispersed and a product manager role is needed to facilitate agreement from, and make decisions on behalf of the customer base. Participatory decision-making tends to produce the most