Can Your Change Management Approach Keep Pace with an Agile Project?

When I was asked to lead Change Management activities on my first Agile software implementation a few years ago, it quickly became obvious that a typical change management approach, which involves performing detailed assessments before creating and implementing change strategies would not work in the context of our project. The team was due to deliver its first release in three months and there were leaders to engage, impacts to mitigate and employees to train. A long drawn-out assessment and strategic planning process would hinder rather than help the project. I quickly set about redesigning our change management approach to fit the Agile methodology. This article summarizes the approach I took to make this happen.

The Challenge

The rate of change in the workplace has accelerated significantly over the years to the point where employees are facing change on a near-constant basis. In the Accenture Pulse of Change survey for 2023, C-Suite executives claimed their organizations faced an all-time high rate of change, and 88% of them expected an even higher rate in 2024.

The Agile implementation approach is of benefit given this reality because it chunks change into smaller amounts so that they can be absorbed more easily, while being adaptable so that project priorities can change as the organization changes.

Faced with a project of this nature, a traditional change management approach where the deliverables are clearly defined upfront and then executed over a period of time became inadequate. As a change team, we needed to be able to update our deliverables as project priorities shifted.

We also needed to walk lockstep with the delivery team. For instance, using a traditional approach, my project plan called for us to spend the first month conducting stakeholder assessments and leader interviews in order to develop a current state assessment. At the end of that first month, the development team was nearing ‘feature complete’ and preparing for testing. While we were developing a change strategy, they would be getting ready to deliver the first set of features to employees who then need to be trained. Based on this timeline there was no time to develop a training strategy, training plan, communication plan and other planning documents called for by our methodology. We had to align our change management activities to the project release schedule.

We also lacked time to develop grand training interventions or complex marketing and communication programs. The window between feature complete and the start of training was two to three weeks for each release. Hence, we needed to figure out a way to work fast and smart, minimize documentation and maximize stakeholder engagement.

For these reasons, using the Agile approach for our Change Management activities made sense.

 What is the Agile Approach?

Agile is an alternative to the traditional approach to software development, popularly referred to as the Waterfall approach. In the Waterfall approach, one phase of a project must be complete before another phase can begin. Using this approach, organizations run the risk that by the time the project is complete, sometimes over a year after the requirements were defined, business realities have changed and the product becomes inadequate immediately upon release.

Agile offers a solution to this challenge. Agile provides opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as Sprints or Iterations, at the end of which teams must present a potentially shippable product increment.

From a change management perspective the Agile approach is high-touch with a lot of focus on stakeholder engagement. It delivers small, frequent changes, rather than a one-time complex transformation.

 The Role of Product Owner

Within the Agile approach, the role of Product Owner is critical. The Product Owner is the key stakeholder for the project. They define the vision for what the end product should be, work with stakeholders to determine what the priorities are, and then work with the project team to prioritize the team’s activities so that the most important features can be delivered first.

We quickly realized that we needed to treat Change Management as its own product being developed and delivered alongside the software. This meant that we needed a Product Owner to be accountable for all of the change management activities. The role of the Change Management Product Owner is similar to that of the software Product Owner. They would help the team define the end state for our change management efforts, and given our limited resources, prioritize those efforts so that we delivered the most important features first. The logical person to act as Change management product owner was the Business Champion since his role on the project was to ensure that the interests of the business were successfully represented. Once we had a Product Owner identified, we set about implementing our Agile approach. 

Implementing the Agile Approach

Step 1: Define the Vision

We worked with the Product Owner to define his change management priorities. These priorities painted for him what success would look like from a people perspective once the project was completed. Consistent with the project approach, we defined these priorities in user story format. User stories are essentially short, simple descriptions of business problems defined with a goal, an actor, and an outcome. They typically follow a simple template: As a {user/actor} I need to {do something} so that {I can achieve some purpose}. User stories are part of an Agile approach that helps shift the focus from writing about requirements to talking about them. All Agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. Creating Change Management user stories in the same manner as software development tasks deeply integrates change management into the Agile process.

Working with the Business Champion, we defined his priorities as follows:

1. As the Business Champion, I would like employees to successfully adopt and be proficient in the new application so that they can use it productively in their work and we can reap the return on the investment made on this project.

2. As the Business Champion, I would like employees and leaders to adopt the new Data Governance framework so that our data quality can remain at a high standard and we can avoid rework and regulatory fines that result from reporting incorrect data.

3. As the Business Champion, I would like to implement a sustainment strategy that will ensure that there is ongoing support of the software and our employees so that the application does not become out of date and our employees can keep their skills current.

4. As the Business Champion, I would like to gain the engagement and buy-in of the leaders within our impacted business units so that they can motivate their employees to commit to the changes required from them.

5. As the Business Champion, I would like information that helps me gauge the level of engagement of employees, and how successful we are in our change management efforts.

These became our high-level user stories or Epics in Agile terminology.

Step 2: Perform Assessment

We then broke down these high-level user stories into smaller chunks so that in line with the Agile methodology, we had user stories that could be completed within a Sprint. For instance, here are some of the lower level user stories that resulted from the first high level story:

As the Business Champion, I would like employees to successfully  adopt and be proficient in the new application so that they can use it productively in their work, and we can reap the return on the investment made on this project.

• As a GIS user, I would like to learn how to use the new Elevation feature so that I can successfully perform hydraulic modeling and simulations to determine an optimal flow model.

• As an Emergency Management team lead, I would like to learn how to use the new Emergency management module so that during an emergency I can quickly collect and upload information without being bogged down trying to figure out how the application works.

• As a Tax Analyst, I need to understand what data to use when creating reports so that I can complete regulatory reports on time and with the right information.

During this assessment phase, we also defined acceptance criteria for each user story. Acceptance criteria helped us to determine when a user story was successfully completed. For the first user story above, we identified them to be:

• 75% of GIS users, and 90% of frequent users have been trained to use the Elevation feature to perform analysis

• 100% of all trained users completed 3 practice exercises.

• 100% of all trained users passed the assessment.

We then assigned a level of effort to each user story – low, medium or high. This was followed by a prioritization effort with the Business Champion where we ranked the user stories from high to low criticality.

At the end of the assessment, we had a backlog of Change Management user stories, assessed by level of effort, and ranked by criticality. 

Step 3: Execute User Stories

We started each Release with a planning meeting. During this meeting, we worked with the Product Owner to identify the user stories we would complete in that release. We broke each user story down into tasks that we needed to do in order to complete the story. Tasks could include creating an online course, setting up a WebEx demonstration, developing a quick reference card, sending an email to communicate key information, identifying Super Users to perform desk checks and hand-hold users immediately following a release, or preparing the service desk to respond to system issues and answer questions.

Next, we determined how many hours it would take to complete each task. This helped us to confirm the level of effort it would take to implement each user story, and thus determine how much of the change management work could realistically be completed within each Sprint.

Once we did this, and assigned resources to each tasks, we then had a plan for our next Release.

 To track progress, we created a scrum board. We printed out the user stories for the current release on index cards and sorted them into relevant columns based on status: Discuss / Prioritize, In Progress, Impeded, and Done. The team had daily 15-minute scrum meetings to discuss status and roadblocks, and weekly status meetings with the Business Owner to update him and see if any priorities needed to change based on the roadblocks that we encountered, or any new information that had come to light. For example, we would sometimes find that we had underestimated the number of hours required to complete a user story. In that situation we had to determine if we wanted to break the story down and defer parts of it to another sprint, defer the entire story, or defer another story to make room for the expanded scope.

We ended each release with a Retrospective during which we reflected on our process for getting the work done. Topics we discussed included:

• What worked and what didn’t?

• What should we do more or less of?

• What roadblocks did we encounter and how could we remove them in preparation for the next Release?

We then weaved the lessons learned from the retrospective into our upcoming planning allowing for innovation and improvement.

The Result

The Agile change management approach allowed us to successfully implement change and learning interventions that ensured that 89% of our users were trained (surpassing our goal of 75%) and user adoption went up by 25% in the new versus the old system.