One question we are often asked by our clients is how do they incorporate change management when they are using an agile project management methodology.
As a reminder of why change management during IT projects is crucial: one of the key areas where we have seen IT development projects fail is in the implementation. Using a change management approach with IT/software projects helps organizations achieve successful implementation and achievement (or often more) of the expected project benefits.
The agile environment lends itself to an ongoing change management approach during development projects
For the change management practitioner, incorporating change management methodology into a more traditional, waterfall, software development approach feels logical.
Upfront you undertake your legacy assessment, understand the scope of change the project will bring, understand your people risks (and plan actions to mitigate them), and plan in appropriate change management, training and communication activities through the life of the project. Perhaps stated a little simply, but you understand the concept.
With an agile project management development lifecycle then the approach to change management also needs to become more agile. In fact, the dynamics of an agile project allows the change management role to become an integral member of the project team, rather than a resource that is called upon when training or communication needs to take place.
Put simply, agile project management takes a risk reduction approach to software development. In today’s fast paced environment we are used to business needs changing quite rapidly. Change management supports, and enhances, the risk reduction approach by identifying and reducing organizational change management, or people, risks.
Agile development allows a project to cope with changes in business needs and requirements by taking bite-sized chunks of work (normally time-boxed so that the sprint, or iteration, can be developed and deployed within a set period of time) and working through the entire development lifecycle: requirements-design-development-testing-deployment, for each iteration.
With agile, project teams have increased internal communication (think daily stand-up meetings), and seek rapid and almost constant user feedback and involvement through the project.
When incorporating your change management approach into such a development environment, you do not need to change what you do, but instead the frequency of, and how, you undertake change management activities. For, example, you could use pulse surveys rather than larger one-off change surveys.
Break down your change management activities into 3 levels
You need to think at three levels when working with agile: Project, Release and Iteration (or Sprint). Here are some pointers to consider when you are planning how to incorporate effective change management into an agile project organization:
At Project Level you still need to undertake some upfront work to gauge the change readiness and people risks associated with the project. At the top level the intent of the project will be to make a change within the organization. While the specific functionality may not be known, the intent will be known at the beginning of the project (change the HR system, improve the website, introduce new call center technology).
- Undertake your Initiative Legacy Assessment and Risk Assessment at the project level. This will give you an understanding of the change readiness of the user groups and the specific people risks you need to mitigate through the project.
- Ensure there is strong, and visible, leadership sponsorship for the project.
- Also consider what communications will be needed at the project level and plan them out in your workstreams.
- Ensure people risks are discussed during standups and other feedback sessions such as retrospectives
A Release is where users will see the actual changes being made. User training, user documentation and communication will be needed for each release.
Gaining feedback from the broader user community and pulling it back into the project for improvements for the next release also help increase the success levels of a project. This feedback could be about specific functionality, about process changes, levels of project engagement, effectiveness of change leadership or general communications, for example.
During each Iteration/Sprint work closely with the project team and ensure that the user voice is heard through design, prototyping and user testing. The best way is to ensure the project uses real users in the project (rather than full time user testers).
Understand how people risks might be impacted by this specific set of functionality and ensure appropriate actions are taken to mitigate the risks.
Agile development requires increased change management involvement
Just considering these pointers it is clear that the role of change management becomes more involved when working with agile projects. To incorporate change management properly into an agile project organization then you will need more than just a handful of change specialists.
Building a mature internal enterprise change management capability within your organization will support the change management needed to successfully deliver agile projects, and enable your organization to remain agile in the long term.
We have developed an easy guide to assess how mature your organization’s change management capability is and how you can increase your ability to support and agile organization. Read more about it in our white paper here.
Introduce more change agility in your organization with Roadmap Pro
If change agility is key for your organization you may also be interested in Roadmap Pro, our innovative new change management toolkit.
It is a completely new digital platform for organizations that must deliver their change projects quickly, comprehensively and cost-effectively.