Enterprise-wide transformational projects that use an Agile approach are often highly disruptive as they bring about tectonic changes in business operations. Change comes fast, frequently and in smaller pieces, meaning immediate disruption.
Add that to the fact that people, by their nature, are inherently resistant to change and it is easy to see that Change Management practitioners have quite a challenge on their hands. Without change adoption, we get a solution without results.
So how do you get people to rapidly adopt change on an Agile project?
You take a focused set of time-tested Change Management tools, deconstruct them, and employ them at the speed of light.
A Tale of Switching Train Tracks
A global consumer goods company with approximately 200 employees and a very entrepreneurial culture decided to switch how it implemented its new ERP system, moving from Waterfall to Agile. They retained Blue Skies to assist with Organization Change Management.
Moving to Agile mid-project brought about its own challenges, since it changed the nature of the change itself. It was like asking people to jump from one train to another as they moved full speed ahead to their destinations. Not only were we moving forward to a new future, but we were also moving laterally and changing how we got there.
This was, understandably, disorienting to some people. But we recognized that the project needed people on board that new train for the transformation to be successful.
How did we accomplish this?
For my role, I had to accept that, as a change practitioner, I had to change how I managed change. I had to shift how I worked, work faster, and do so in less time.
Tried and true Change Management tools, templates, and best practices I had used in the prior part of the project wouldn’t work the same way moving forward. They were too slow for a rapid Agile pace.
Find a Unique Approach
While every Change Management project will take a slightly different approach, Agile projects are unique. It is a bit of the old “rip the Band-Aid off” experience: the change adoption curve is high but over quickly. For this project, here is what worked for us.
We prioritized a high level of engagement with the business and face-to-face presence. The more “there” we were, the easier it was to respond quicker to more frequent and sudden changes to plans. Plans, in fact, became living documents; they were constantly adjusted and were more “now,” less “perfect.” This engagement also allowed us to provide informal coaching faster to address pockets of resistance as they cropped up.
We also had tight integration with the Agile team: we merged the people side of change with the technical side of change, deepening relationships with functional (tech) consulting experts, and matching our cadence with the rapid pace of releases.
We also had faster and more frequent communications aimed toward specific audiences. With a just-in-time approach, messages were shorter, less formal, delivered faster, and how people liked to receive them. We only sent communications to those who were impacted rather than blanketing and bombarding everyone with every message.
We also required more involvement of team members and stakeholders for shorter periods of time. We worked with execs, those accountable for outcomes, heads of departments, and senior managers to endorse the future state, gain commitment for required work effort allocation, remove roadblocks, and move people up the change curve.
We saw intense functional area vertical involvement for short periods of time. Our aim was to get people involved, focused, and engaged, from bottom to top.
The Change Plan
With this approach in mind, here’s what the change plan looked like.
Before executing the plan: We leveraged institutional knowledge and relationships as inputs into the upfront OCM planning phase. Change Management at the speed of light requires more preplanning, extending preliminary activities such as upfront communications (on what Agile is, expected time commitment, changes to OCM approach, and expected changes), and stakeholder engagement (prepping for socialization).
Before sprints: We increased awareness of upcoming changes and articulated a compelling story that linked to the business vision, as well as stated the business case for change and how we were going to get there.
During a sprint: Key Change Management activities surrounded sustaining engagement, identifying focused change impacts, frequent communication, and resistance management. The plans evolved quickly as the Agile project did. Less planning time means less standardization and renders traditional templates less relevant.
End of a sprint: We supported knowledge transfer through engagement in development and testing as well at short bursts of training sessions.
After a sprint: We reinforced change with formalized Super User Networks, made employee “goals and objectives” changes where needed, and monitored adoption of change over time.
Project success occurs when a well-functioning technology system meets competent and confident end-users and other stakeholders. Think of these as two train tracks merging together, one a “people” track, the other a “technology” track.
But no matter how much work is put into the project plan, the ultimate project success is when the change is sustained over time.
Lessons Learned Along the Way
As with any project, the team learned a few things along the way.
First, Change Management can be a great match for an Agile approach. Both are known for being iterative and dynamic. Combining the two requires an even higher degree of flexibility and rapid execution.
Perfect is the Enemy of Good
Change practitioners don’t have time to employ a comprehensive suite of tools in Agile projects due to the speed of the change. You need to be tactical, targeted, and open to experimenting with approaches. Agile, by its nature, has many iterations, which makes perfection impossible and moot.
Letting Go Can Mean Being in Control
Know when and where to flex your plan and adjust your definition of success. It can feel like letting go of control for a change practitioner, but it actually has a paradoxical effect. Knowing when to let go of some plans or stop using some tools can put you in more control because you are adapting to your situation quickly.
OCM Understanding is Imperative
Change Management can’t happen at the speed of light if people don’t understand what it is and how to engage with change practitioners. Ultimately, communication is key, particularly with the goal of explaining why Change Management is better not just for the organization but for everyone involved in a project.