Agile Change Management
Recently, I have discussed why change management should be an integral part of an agile adoption program. Now we will invert the discussion and discuss why doing change management in an agile way is an ideal approach for any kind of (organizational) change initiative. First we will revisit why we need change management and then discuss why Agile change management is exceptionally well-suited for change programs.
Why we need change management
As sponsors of change initiatives, we often are confident that everyone in our organization will be better off once the change is implemented. We may believe that the value of the change initiative is so self-evident that as soon as the initiative is announced everyone will be eager to immediately adopt the change. In this fantasy, the change initiative profile looks something like this:
However, as we recently discussed, experience tells us that successful change initiatives look more like this:
Things don’t get better right away. In fact things get worse before they get better. Does it really have to be this way? Lets try to imagine a case where the ideal change initiative might pertain.
The instant that the change initiative began, all parties would instantly:
- Understand what the change objective is;
- Agree that they want to pursue the change initiative;
- Know everything they needed to know to change;
- Be able to implement the change;
- Be able to execute and sustain the change without practice.
Essentially, all five phases of the ADKAR model we previously discussed would need to happen instantaneously for everyone AND all other changes in operations such as policy, platform, and infrastructure changes would also need to occur instantaneously. Collectively, we can refer to these considerations as the operational requirements or implementation costs of the change initiative.
Upon inspection, it becomes clear that for most change initiatives there are significant implementation costs. Therefore, every change initiative needs a business case to make sure that the cost of implementing the change is worth the anticipated return. In addition, every change initiative needs program management to make sure that the operational requirements are effectively implemented. In this regard, the program for implementing a change initiative looks pretty much like the program for building a swimming pool in your back yard. For both, you need to manage task performance, while mitigating schedule and cost overruns.
It’s probably fairly clear at this point that program management is helpful if not essential to assure that the operational requirements of change initiatives are effectively met. Is that all we need to do to assure success? Let’s revisit our backyard swimming pool project.
Why traditional program management is not sufficient
We have plenty of reasons for feeling certain that our swimming pool project will be a success. We have a fixed-cost contract from a bonded, reputable dealer. We know exactly where in the yard the swimming pool will be placed. We have been swimming in similar pools, so we know what kind of experience to expect. The project plan provides a further level of assurance that our expectations will be met regarding the pool, the schedule, and the price. However, what if the reason we are putting a pool in the backyard is because we hope that it will keep our kids at home during their teen years? Even if the pool is implemented perfectly, the pool project will still be a failure if our kids are rarely home. In this case the success of the pool project is inherently uncertain because success is contingent upon human motivations and decisions that are difficult if not impossible to predict. The best pool implementation plan in the world will not help us reduce this uncertainty.
The example above illustrates a point that we have discussed before: the distinction between risk and uncertainty first made by the economistFrank Knight.
||Know event will occur
||Know probability event will occur
As we see in the above table, with risk we may not know for sure that something will happen but we do have a good idea of its probability of occurring. Certainty is a special case of risk where the risk of failure is zero percent. From a practical perspective, we often treat things with a very high likelihood of occurring as if they were certain. Uncertainty is very different from the other two because we have no quantitative basis to predict the likelihood of a future event occurring.
The risk of a successful pool implementation can be effectively managed using traditional program management techniques. However, traditional program management techniques are not designed to guarantee outcomes that are inherently uncertain, such as estimating the likelihood that your kids will hang out at home during their teen years. Turns out there is plenty of uncertainty in most change initiatives. Let’s discuss three kinds:
- Human motivations often remain hidden from our view.
For change initiatives to succeed, stakeholders must be motivated to change. Although we may believe we have the right carrots and sticks in place, we can never be fully informed about what makes our employees tick. Therefore, how stakeholders will react is inescapably uncertain. Although we may think building a company pool will motivate employees to spend more time at the office, it may not turn out that way because of complex or hidden motivations (afraid of water, hate myself in a swimsuit, etc.) that run counter to our pool value proposition.
- The future is inherently vague.
Once we remove our kid’s future behavior as a criterion, we are pretty confident that our pool project will be a success because our vision of a backyard pool is quite concrete . In fact it pretty much matches the pool in the brochure, once we substitute into the picture our own backyard. In contrast, no one knows how change initiatives will turn out. Since change initiatives don’t have outcomes you can illustrate in a brochure, their final outcomes are inherently vague — which is to say uncertain. This uncertainty is only fully resolved when the final form of the change initiative has emerged at project end.
- Once groups fall out of equilibrium, you can’t predict what will happen.
As we briefly discussed not long ago, the status quo represents a dynamic equilibrium within the organization whereby individuals participating in groups mutually reinforce persistence in behavior and expectations. The balancing of the respective interests and motivation of all parties are in effect bound and constrained within the shared organizational framework of current practices and policies. When the change catalyst disrupts this equilibrium (as it necessarily must do so that change can occur), it will be impossible to predict exactly where and when (or even if) a new dynamic equilibrium will be restored. One reason why people let sleeping dogs lie.
We can see that to assure the success of our change initiatives in addition to implementing operational requirements, we must also navigate through significant uncertainty.
An Agile approach to change management
Someone counseling the parents trying to entice their children by bribing them with a swimming pool might have suggested there is a better way to engage. Although their objective might be laudable, their means is dubious and could even create side effects that move them further rather than closer to their goal. Why, might their children ask, if home is such a good place for me to be, do my parents feel that a bribe is necessary to keep me there? What part of my parents motivations remain hidden and why?
The carrots and sticks that accompany the best intentioned change initiatives may backfire and end up increasing rather than reducing uncertainty if perceived as overly manipulative or worse — masking a hidden agenda. In this case perception is reality.
Agile methods don’t allow us to manage uncertainty as we might manage risk, but they do help us manage through uncertainty and live to tell the tale. Since we can never know enough to plot a fool-proof course, we recognize we must learn as we go and make course corrections along the way. We progress in baby steps. We take a step, take stock of what we have learned, reshape our plan accordingly, and then we take another step.
The following section shows how these principles can be applied to a change initiative through the use of multi-level planning, a core concept of Scrum project management.
For those familiar with Scrum this section may look familiar. For those of you learning about Scrum the following section illustrates how Agile planning can be applied to a project that has nothing to do with software development.
The Sponsor starts the initiative by circulating a draft vision statement. The vision is a brief, aspirational view of what the future might be, if the change initiative is successfully implemented. All affected parties are invited to respond to and participate in the change initiative. The sponsor uses the feedback received to refine the vision and prepare a draft roadmap, the second level planning.
The road map is a high level plan that shows the sequence of key milestones (e.g. train staff on new systems) over the course of the change initiative. Whereas the vision is a high-level description of the intended outcome, the roadmap is a high level view of what must be done to get there. A draft roadmap (and possibly a revised vision statement) is circulated to the stakeholders to inform them of what will happen, but also to obtain more feedback and further agreement to participate.
The third level is the implementation schedule (called the release plan for software projects). The implementation schedule projects the number and sequence of work iterations (see below) necessary to deliver key milestones and ultimately to achieve the desired future state. Previously senior management asked stakeholders to respond to plan elements, this time everyone who has delivery responsibility is invited to collaboratively produce the implementation schedule and point out task dependencies. On the basis of more detailed planning and a broader base of planners the roadmap schedule may be revised.
The implementation plan is comprised of work iterations (called sprints or iterations in Agile software development). Work iterations are short (1 week to 1 month) timeboxes. Each iteration involves three steps: planning, work, and review, all of which take place during the iteration. Planning involves pulling tasks from a prioritized backlog, completing their definition, and scheduling. Only at this point, the moment before work begins, is the implementation plan complete. And it is only complete for the current iteration. At the end of the iteration, the work effort is reviewed. If the need for new work is discovered, it is added to the backlog. Or perhaps an emergent issue is identified (e.g., training is taking twice as long as was originally estimated) that must be addressed. As iterations are completed, the actual rate of progress can be used to verify or if necessary recalibrate the implementation schedule. Program managers may also change the priorities of backlog tasks on the basis of most recent feedback. As we can see, the planning process is incrementally completed and dynamically adjusted over the course of the initiative on the basis of emerging conditions and new information. In addition, the final commitment to schedule and acceptance is completed by the people that will conduct the work. Collaborative planning has now been fully extended to everyone charged with performing initiative work. Depending on the initiative, this may include every change initiative stakeholder.
The lowest level plan is the daily plan (called the Daily Standup in Scrum). People who are working together on the current work iteration, discuss daily what they accomplished the day before, what they hope to do today and if anything is blocking their progress. This daily planning cycle helps determine instantly if the current work iteration is on track. The moment that a blocking issue is identified it is identified and escalated as necessary to the proper level of program or executive management.
Let’s consider now how multi-level planning addresses the three root causes of uncertainty we previously identified.
Human motivations are often obscure. Agility can’t change human nature but it can accommodate it. From the very beginning, the change sponsor invites the stakeholders not only to participate in but to shape the change initiative. The sponsor candidly admits what they don’t know and invites others to fill in the blanks, while broadly sharing the true and emerging status of the initiative. By changing course in response to concerns the sponsor demonstrates that they not only are in touch with reality but responsive to staff concerns and emergent problems. What might have been your (i.e. the change sponsor) initiative becomes our (i.e. all stakeholders) initiative.
Motivations may be obscure, but behavior is easy enough to ascertain if you bother to observe. Incrementally and more and more, are stakeholders responding, collaborating, and committing? If the answer is yes, there is cause for confidence that you are on the right track. If the answer is no, the initiative won’t progress beyond its earliest stage and can be stopped or revised before lasting damage occurs.
The future is inherently vague. Agile change management never positions the change sponsor as knowing more than they could possibly know. Management might think that the best tonic for uncertainty is to boldly claim that they have already thought of everything so there is no cause for concern. When management presents a fully-baked implementation plan at the start of the initiative, that’s just what is implied. This is a risky path to take. Since management really doesn’t know everything up front, the fact that things are going awry will often be obvious to the staff before it is to management. However, now the staff is in a tough spot. To advise management that they are on the wrong track means contradicting management’s statement that “everything is under control.” What is staff more likely to do? Risk being called out as uncooperative and overly negative or remain mum and wait for management to fail?
Agile change management does not provide a crystal ball. But it does provide ways to keep track of the emergent state of the evolving change initiative and to broadly share it. Perhaps most important, it expects that plan will need to adapt rapidly and frequently over the course of the initiative.
Volatility of destabilized social systems. Since Agility expects change and the need to adapt to this change, it provides tools to stay tuned to developing conditions minute by minute. If for whatever reasons (rumor will, unanticipated consequences), negative patterns start to emerge, they can be addressed in a timely manner and before they get out of hand.
People often claim that people don’t like to change and that is why they often appear vigorously to resist change. Would we also claim that people resist opportunities to progress? That their fear of change so paralyzes people that they can’t see what is in their own interest? Perhaps what people really don’t like is uncertainty. When confronted with a need to change with gravely uncertain results, resistance seems a reasonable response.
Agile change management provides us a way to manage through the uncertainty that is endemic to change initiatives. We might be surprised to learn that when offered the opportunity to change in an agile way, people don’t resist change but embrace it.