“What do you mean there’s no big bang release date? How will we know what to build if we don’t know what the thing will do far in advance? How can we train people to use something if we don’t have all the user requirements and specs up front?” Such questions ring through the hallways of companies making the transition from a waterfall to an agile way of designing and delivering software.
Even companies that pride themselves on being agile may struggle with what comes next, once their MVP is code complete. Many of our clients struggle with how to bring users along for the change as they develop their software iteratively. If they focused on change management at all in the past, they usually did so with an all-or-nothing mindset, with a specific release deadline and lots of effort leading up to a big bang release. This model doesn’t work in an agile environment where the product is never “done” and where new functionality, features, and products are constantly being developed, piloted and adapted.
1. Willing: “I want to do this.’’
2. Able: “I know how to do this.”
3. Ready: “Okay, let’s do this”/ “I am going to do this.”
Exhibit 1: WAR: Are your users willing, able and ready?
Using an agile change management approach, the product team aligned its change efforts to the iterative development cycle:
Discovery: Together, members of the cross-functional team aligned on the “big why” with the business leadership, helping to shape a compelling vision that would act as the North Star throughout development. They used personas to identify the needs, expectations, and reservations of the various stakeholder groups to help shape the outlines of the plan. They also laid out plans for how to educate users about the agile journey.
Inception: As the team agreed on the MVP and the initial thin slice of functionality to deliver, the members responsible for launch and adoption also considered the question: “What is the thinnest slice we can take to achieve initial results?” What is an acceptable pilot? What will be the impact of the initial functionality and what is the simplest way to repeat and test relevant training? What is an acceptable low fidelity way to begin communication? What are the most important messages to convey at first?
MVP Delivery: As the developers were working on the minimal viable product, the team members responsible for managing change also worked with an MVP mindset, for both content and delivery. Rather than building a big training plan highlighting all the benefits and functionality of a future product, they engaged pilot teams with “just enough” bite-sized training modules. Instead of investing a significant amount of time and resources in sophisticated communications at the beginning they started with simple, lower fidelity tools that could be tested and adapted quickly to user feedback.
Iterative Development: Following the rollout of the MVP, the change management activities kept pace with the expanding and evolving functionality. As the design team workshopped the product and gathered feedback from customers, this input was incorporated into training and communications materials. Members of pilot groups became change champions who became advocates across expanding networks. And with each iteration, not only the content but the format of the change and communication tools evolved to become more sophisticated and robust:
Stakeholder alignment: From small workshops and one-on-one meetings to cross-functional design sessions to product champions to champion network
Communication: From individual slides and email blasts to product roadshows to all-company exhibitions
Training: From in-person demonstrations to recorded videos to self-paced digital tutorials
Business readiness: From individual paper checklists to crowdsourced task lists to automated onboarding
Even companies that pride themselves on being agile may struggle with what comes next, once their MVP is code complete. Many of our clients struggle with how to bring users along for the change as they develop their software iteratively. If they focused on change management at all in the past, they usually did so with an all-or-nothing mindset, with a specific release deadline and lots of effort leading up to a big bang release. This model doesn’t work in an agile environment where the product is never “done” and where new functionality, features, and products are constantly being developed, piloted and adapted.
Supporting change: Willing, able and ready (WAR)
Regardless of how a technology product is rolled out, the most challenging part is almost always user adoption. I often tease clients that “technology is easy, it’s people that are difficult” because of our preconceptions, habits, and preferences. Technology adoption will always be challenging unless we equip users to accept it. We are used to the phrase, “ready, willing and able,” but I think that the more logical and effective progression is:1. Willing: “I want to do this.’’
2. Able: “I know how to do this.”
3. Ready: “Okay, let’s do this”/ “I am going to do this.”
Exhibit 1: WAR: Are your users willing, able and ready?
To make change stick: The agile change plan
Every good change management plan has the same basic elements: leadership and stakeholder alignment, communication, training, and activities to support business readiness.
Exhibit 2: Planning for change
Exhibit 2: Planning for change
How agile change management is different
What we have found is that agile change management means not only introducing users to and involving them in the development of new products and platforms, but also influencing them to think differently about the process. In an agile change program, activities have a slightly different flavor than in traditional programs. Just as discovery and development are continuous and iterative, so too are the change management activities.
Exhibit 3: Agile change management - The difference
Agile OCM (Organizational Change Management) in action
“This approach makes so much sense and thinking about what being ‘willing, able and ready’ really helped us to develop a good plan. Understanding that we also could take an agile approach to our launch and adoption activities made it a much more manageable and sustainable process.” (Client launch manager/change lead)
Recently, I have been working with a major retailer to implement a custom service platform which is used by both internal and external users. It is designed to replace multiple existing systems and a plethora of currently heavily manual processes. Naturally, a transformation of this magnitude takes some time to achieve, but that doesn’t mean that real business value cannot be achieved with smaller chunks of functionality delivered at more frequent intervals.Using an agile change management approach, the product team aligned its change efforts to the iterative development cycle:
Discovery: Together, members of the cross-functional team aligned on the “big why” with the business leadership, helping to shape a compelling vision that would act as the North Star throughout development. They used personas to identify the needs, expectations, and reservations of the various stakeholder groups to help shape the outlines of the plan. They also laid out plans for how to educate users about the agile journey.
Inception: As the team agreed on the MVP and the initial thin slice of functionality to deliver, the members responsible for launch and adoption also considered the question: “What is the thinnest slice we can take to achieve initial results?” What is an acceptable pilot? What will be the impact of the initial functionality and what is the simplest way to repeat and test relevant training? What is an acceptable low fidelity way to begin communication? What are the most important messages to convey at first?
MVP Delivery: As the developers were working on the minimal viable product, the team members responsible for managing change also worked with an MVP mindset, for both content and delivery. Rather than building a big training plan highlighting all the benefits and functionality of a future product, they engaged pilot teams with “just enough” bite-sized training modules. Instead of investing a significant amount of time and resources in sophisticated communications at the beginning they started with simple, lower fidelity tools that could be tested and adapted quickly to user feedback.
Iterative Development: Following the rollout of the MVP, the change management activities kept pace with the expanding and evolving functionality. As the design team workshopped the product and gathered feedback from customers, this input was incorporated into training and communications materials. Members of pilot groups became change champions who became advocates across expanding networks. And with each iteration, not only the content but the format of the change and communication tools evolved to become more sophisticated and robust:
Stakeholder alignment: From small workshops and one-on-one meetings to cross-functional design sessions to product champions to champion network
Communication: From individual slides and email blasts to product roadshows to all-company exhibitions
Training: From in-person demonstrations to recorded videos to self-paced digital tutorials
Business readiness: From individual paper checklists to crowdsourced task lists to automated onboarding
The takeaway
For any major change, product and development teams must take their users along on a journey, preparing them to be willing, able and ready to embrace the new product. The best way to do this is not with lofty expectations for massive big-bang transformation in one go. Rather, it is with a flexible, constantly evolving program of tools and activities that, like the product itself, start with an MVP then expand and evolve in response to user feedback.Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
