Change Agility
Context
“Let’s begin by discussing why this change is important. Write down your thoughts on sticky notes and place them on the Change Canvas.”
Crickets. The room went completely silent.
After a few awkward moments, one brave soul said, “Because the organization wants to automate our roles.”
Nope. Not even close.
Here we were, 11 months into Project MOVE, ahead of schedule and going live in 30 days, yet the impacted team didn’t understand the purpose of the change.
In fact, they were completely misaligned.
This misalignment went unnoticed by the executive sponsor, project manager, and the project team until there was infighting, resignations, and productivity and morale had tanked.
Until recently, the project had been viewed as a major success story, and the sponsor was using the fact that the project was ahead of schedule as evidence of its “agility.”
The project had been handling communications on their own and did not engage change management support (me) until everything started to fall apart 30 days from go-live.
Project MOVE had set up a SharePoint site and pushed out multiple communications over the past 11 months.
So, how did we get here?
The Big Idea
Despite being months ahead of schedule for deployment, Project MOVE lacked agility.
The concept of “agility” has become conflated with “velocity.”
Velocity is how fast you can push change out the door to stakeholders.
Agility is how fast you can pivot direction to meet stakeholder requirements.
Change agility is not about how fast you can deliver change — it’s about how fast you can pivot your approach to change.
You can’t just do change faster at people by pushing out communications, interventions, and changes with increasing velocity, because people and systems of people have a limited capacity to unlearn and relearn.
The whole point of agility is to uncover what stakeholders value—what they care about and what they don’t care about—so that you can develop a solution that addresses their needs.
Change agility is a culture of deep collaboration, co-creation, experimentation, and sense-making with stakeholders, so that together you can learn your way forward through change.
It’s about having a big picture vision of where you are headed, while being able to change direction in the here and now as new paths emerge.
Change agility is about moving away from “checkbox” change management and blindly following a plan, towards making frequent adjustments to the plan and approach based on just-in-time learning.
It’s about delivering the right communications, the right messages, and the rightinterventions, at the right time.
If you accept this, then what follows is a potentially startling conclusion:
Agility can slow you down.
Sometimes the right thing to do now is nothing.
Organizational change is emergent. No one—not even the stakeholders themselves—can fully anticipate their requirements in advance.
Project MOVE was ahead of schedule in terms of development and deployment—it had velocity— but it had failed to understand and pivot direction to address emerging stakeholder needs and concerns—it lacked agility.
The reason it lacked agility was because the project team focused on one-way push communications with no feedback loops built into the process.
How I handle This Challenge
Change agility requires a workflow that enables you to pivot quickly and adjust direction based on short feedback cycles.
I developed what I call “the three Ms mental model” to help think through this:
Minimize time to pivoting by
Minimizing time to learning by
Minimizing time to action
Minimize Time to Action
What: I embrace the experimental mindset that moves me away from thinking I need to know everything in advance, to one where I am OK with testing and learning my way forward.
Why: All organizations are complex adaptive systems in which change is emergent and non-deterministic. We can’t know or plan for everything in advance. We need to try things out and observe the feedback from the system.
How: I work in short iterations of 1-2 weeks. At the beginning of each iteration, I select the three most important experiments and activities to complete, with a bias towards engaging directly with stakeholders. I then focus my attention during the iteration on execution.
Minimize Time to Learning
What: I am intentional about reflecting on and learning from the feedback I receive as a result of my continuous actions.
Why: Feedback from the system is validated learning. It is the only way to know whether I am moving the needle and doing things that matter to stakeholders and add value for them.
How: I build in standing retrospectives at the beginning or end of each of my iterations to intentionally review the results of my experiments. This doesn’t have to be complicated – one 30-minute session every week or two is all I need.
Minimize Time to Pivoting
What: My process enables me to pivot direction after each iteration if that’s what needs to be done.
Why: Pivoting based on emerging stakeholder requirements is the definition of change agility.
How: I always use a pull-based process of work. I use Kanban boards and a Minimum Viable Change Process to constantly re-evaluate the work and pull the most valuable work forward.
