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

a daily scrum meeting in which each team member must answer the following three questions:

• What have you done since the last scrum?
• What will you do between now and the next scrum?
• What got in your way of doing work?

Issues that arise which may impact a task are raised during the daily scrum and might be added to the sprint backlog or the product backlog based upon the customer's decision. At the end of a sprint, a sprint review is held to present the product increment to the customers for evaluation to ensure it has met the agreed upon sprint goals and satisfied the specified requirements for each request in the completed sprint backlog.

What's so "Agile" about that?

The first step toward agile change management is a change in mind-set! Those of us who think of change control as preventing changes to an agreed upon "baseline" of project/product scope must change our mind-set to embrace change as a natural and expected part of development. The focus needs to shift from preventing change, to managing expectations and tracking changes. Instead of saying "No!" to a change request, the "agile" answer should simply inform the customer of the associated risk and impact upon the currently agreed upon cost, schedule, scope and quality, and then let the customer make an informed decision. This is what the fourth "value" of the Agile Manifesto [3] implies when it espouses " Responding to change over following a plan." 

If agility is defined as "the ability to both create and respond to change in order to profit in a turbulent business environment" [4], then agile change management must help us do these two things:

• 1. Be more responsive to requests for change
• 2. More quickly and easily implement those changes

As mentioned in an earlier column [5] , responding quickly and effectively to change is easiest to do when we can minimize the following:

• The cost of knowledge-transfer between individuals
• The amount of knowledge that must be captured in intermediate artifacts
• The duration of time between making a project decision, and exploring its results to learn the consequences of implementing that decision

Agile methods enable projects to be more responsive to requests for change by:

• a) Using short and frequent iterations to minimize the time between specifying a requirement and seeing it implemented so that adjustments to functionality and priorities can be recognized sooner rather than later
• b) Requiring developers and customers to communicate and work together daily (co-located together if possible) so that change-control decisions can be made and communicated quickly and communicated face-to-face with minimal waiting and documentation
• c) Allowing and accommodating (even encouraging) changes in scope and priorities via a highly collaborative agreement process that informs the customer of impact and risk, and puts the customer in control of the scope and priorities
• d) Authorizing and empowering team members to correct problems with the code's behavior and structure without having to suffer delays waiting for formal change proposal, review, and authorization of such corrective changes

These four things together are what help transform traditional contract negotiation into customer collaboration, in accordance with the third "value" of the Agile Manifesto . 

Agile methods enable projects to more quickly and easily implement changes by:

• a) Working in short but complete cycles on the smallest possible "quanta" of work with tight feedback loops (e.g., short iterations, test-driven development, pair programming, continuous integration, etc. [1], [2] and [4] )
• b) Mandating simple design, and emergent design methods (like refactoring [6]) to make the code as simple and easy as possible to change
• c)