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

details.)

Then the customer decides which requests they want implemented during the next iteration. They do this based upon the iteration length, the estimates for each request, and their stated priorities about which requests are the most important. The customer may completely change priorities from one iteration to the next. This is okay as long as development and project management agree the result can be successfully implemented within the scheduled period.

Once customers decide the requests to implement for an iteration, developers sign up for "stories" to implement and may work only on stories for that iteration. Developers dialogue with customers to elaborate the details of a story. To capture these requirements, customers write acceptance tests for each story on the back of its corresponding index card.

When a request has been implemented, integrated and tested, the corresponding story card is placed upon a big visible chart that shows it as completed. The chart also conveys the number of passed versus still-to-be-passed test cases.

During an iteration, customers may reprioritize unimplemented stories, and remove or replace stories provided that the overall estimated effort remains within the planned iteration end-date. Developers are permitted and trusted to make refactoring changes, or code clarity improvements (or coding standard violation corrections), and to fix any problems encountered, provided it doesn't impact the schedule of their current "story."

There is a brief daily stand-up meeting where each team member quickly gives the status of what they have been working on since the previous day's meeting. If an issue threatens on-time completion of their task, the issue is raised to the customer or project manager, either "on the spot" (with the onsite customer ) or in the daily stand-up meeting. The customer then decides the course of action to take, based on the verbally communicated risk and impact, and the possible set of alternatives)=.

At the end of the iteration (and for each build during the iteration, when feasible) all the completed (and preferably automated) customer acceptance tests are executed to ensure that the built result conforms to what the customers specified in the tests.

Agile Change Management in Scrum

What Scrum does for change management looks very similar to what XP does (see [2]). A large part of this is because some of the project management practices in XP were borrowed directly from Scrum. In fact the daily stand-up meeting in XP is what Scrum calls a scrum and is how the method got its name:

A " scrum" is a rugby term that refers to when all the players on a team quickly huddle together to decide what they are going to do for the next play. They have to do this very quickly because the play is "live" and the clock is running during the huddled scrum.

Scrum divides development up into iterations called sprints. Each sprint is approximately 30 days and delivers an executable product increment of agreed upon functionality from the product backlog . Scrum maintains two formal backlogs of requests: a product backlog and a sprint backlog :

• The product backlog is "an evolving, prioritized queue of business and technical functionality that needs to be developed into a system" [2]. Only the product owner (the person empowered to represent customer priorities) may prioritize the backlog.
• The sprint backlog is the list of all requests to work in the current iteration (sprint).

The content of the sprint backlog is agreed upon by the product owner at the beginning of planning for the sprint (very similar to the planning game in XP). During the sprint, there is