Agile Change Management

Agile delivery comes from software development. The Manifesto for Agile Software Development (2001) set out four values, among them "responding to change over following a plan", and twelve principles that favor frequent delivery of working software and close collaboration with users. Frameworks such as Scrum turn these ideas into a routine: work is pulled from a backlog and delivered in sprints of one month or less.

Agile delivery changes the rhythm of change for the people affected. Instead of one go-live after months of design, they receive a steady stream of smaller changes, each of which still has to be understood, learned and used.

Agile change management is the discipline of supporting people through that stream. It is not a single model with fixed steps: practitioner writers such as Melanie Franklin describe it in their own terms, and organizations adapt it to their delivery method.

Agile change management is therefore change management paced to iterative delivery, not a replacement for it.

The activities stay familiar: impact assessment, engagement, communication, learning, support and reinforcement. What changes is their size, timing and frequency.

The change manager also moves closer to the delivery team, often joining its planning and review events rather than receiving a finished design.

Agile change management therefore asks for smaller, more frequent change work, planned close to the delivery team.

A change backlog is an ordered list of the change activities a release will need: a briefing for team leaders, a short guide, an update to a procedure, a drop-in session, a question to test with users. Each item is linked to the feature or release that creates the need.

The change manager orders the backlog by the impact on people and by the release dates, and reviews it with the product owner so that change work is visible next to delivery work. Some teams add adoption conditions to their definition of done, for example "guidance published and team leaders briefed", so that a feature is not called finished while people cannot yet use it.

Feedback from users becomes new backlog items, for the change team or, when it points to a design problem, for the delivery team.

A change backlog makes agile change management plannable in the same way as the delivery work it supports.

Scrum's events give natural points to connect change work to delivery:

• Sprint planning: check which selected items affect people, and plan the change items they need.
• Sprint review: invite representatives of the people affected, and record their reactions as feedback.
• Retrospective: include adoption lessons, not only delivery lessons.

The pace at which a team delivers does not have to be the pace at which people receive change. At Brightwater Health, a scheduling team works in two-week sprints, but the change manager agrees with the product owner to release new features to clinics once a month. Before each release, clinic managers receive a one-page "what is changing" note and run a short team huddle. Change agents in each clinic collect questions, which go into the change backlog for the next month.

Agile change management therefore separates the delivery cadence from the adoption cadence when people need time to absorb each step.

Iterative adoption has real advantages. Small changes are easier to learn than large ones. Users see early benefits and can influence later increments, which builds ownership. Problems surface in one release instead of all at once.

It also brings risks:

• Change fatigue. A constant flow of small changes, added to other initiatives, can exhaust people.
• No clear ending. People may never feel that the change is complete or that the old way has ended.
• Lost story. Seen release by release, the change can look like a series of tweaks with no purpose.

The usual answers are to bundle small changes into fewer releases, to keep a stable picture of the end goal and a visible roadmap, and to mark milestones so that people can see progress.

Agile change management works best when every increment is presented as a step toward a purpose people understand.

The evidence base is thin. A systematic review of large-scale agile transformations by Dikert, Paasivaara and Lassenius (2016) found that most published accounts were experience reports rather than research studies, and listed change resistance among the recurring challenges and training, coaching and communication among the success factors. That review concerns adopting agile itself, which is related to, but not the same as, managing other changes through agile delivery.

Common mistakes include:

• treating "agile" as a reason to skip change planning;
• keeping the change manager outside the team, so impacts are found late;
• equating "released" with "adopted";
• ignoring the parts of the organization that do not work in sprints, such as operations or HR.

Agile change management is therefore a practical adaptation with limited research behind it, and it still needs a clear strategy and measures of adoption.