Change Management Within an Agile Project Environment

In a previous blog we explored what it means to work with an agile mindset– to be nimble and flexible – ready to pounce on opportunities, or to change course to avoid inevitable problems and unnecessary cost.  Now we’re thinking specifically about Agile Methodology and what that means for the end user of new systems and business processes.

Running an Agile project is good news for many of our clients as value can be realised sooner due to the incremental, iterative approach. But it does mean that the way we approach change management has to evolve when the to-be solution is being developed at pace and may change along the lifecycle.

What we see is the typical set up where the Scrum Manager facilitates the development team, and the Product Owner represents the business, working with the user group to determine the features within a product release.  This takes care of ‘who’ and ‘what’, but who is considering the ‘how’?  How are you going to prepare the end users for changes? How are you going to help them adopt and embed the changes?

Here are our five top tips on integrating change management with Agile project management to speed up adoption and value release:

1. The Project Triangle – Product Owner, Scrum Master and Change Manager

In our experience Agile methodology has been seen as the panacea in gaining adoption and usage of new systems and business processes, as users will get what they want faster, right?…wrong!  Where we have seen Agile projects be truly successful, businesses were able to think further ahead and tell a bigger story to users, ensuring that change was on the agenda from the outset and embedded within the project team structure.  In this way, the voice of the user is at the forefront of project planning and by working closely with the product manager, the change manager made sense of project complexity and brought clarity to the business.  When the change manager supported business validation within each sprint, the level of engagement was closely tracked; where resistance was met it was understood and mitigated.

As with many Agile projects, there is often regular re-planning as priorities change, roadblocks or challenges come up, and issues are identified and resolved. The Scrum Master is in the centre of this re-planning – it’s key for the Change Manager to keep abreast of changes to delivery timelines to ensure the business is kept informed and engaged.

2. Up front engagement

In an Agile environment, user adoption is all about engagement.  In our experience this engagement should be ‘front-loaded’ so that stakeholders and end users really understand the Agile process and what’s likely to happen, how decisions will get made, what is expected from them and most importantly to express how they will benefit before any releases have happened. Without this early engagement you may find that users who are used to a traditional waterfall project approach are confused or concerned by the pace associated with Agile and the lack of certainty on what the end solution looks like.

A blend of communication methods should be employed, from senior leader advocacy and sponsorship to lead user/super user engagement workshops coupled with clear, concise and impactful communications material.  As with any engagement approach, getting feedback from users is vital.  Test your thinking and be ready to increase the amount of engagement tactics as this will pay dividends later in the project.

3. Prepare to be flexible

You’re not running a traditional waterfall-style change plan here, so you’ll need to constantly revisit the change management tactics to make sure the right people are being updated with the most important information as and when it happens. Proactivity and flexibility is key and this links back to ensuring there’s a great working relationship between your Product Owner, Scrum Master and Change Manager – without this synergy the communications and engagement could get left behind or worse, be ill-informed and resulting adoption will suffer.

We recently supported a big data project which had a fundamental change of direction early on – it became apparent that a major value driver of the project was much more complex and time consuming to deliver than initially thought, and was deferred indefinitely, which was a big risk to stakeholder engagement.  We were able to flex all of the planned change and communications activities, to tell the story of what was changing and why. This allowed the project team to pivot and bring new, high value functionality to the business quickly.  This was possible due to the close knit team with clear roles and responsibilities and with change governance clearly laid out.  We were able to bring stakeholders on the journey through close and transparent engagement; explaining the options, costs and benefits, and genuinely seeking their feedback.  As with Agile methodology itself, you have to prepare and put the thinking time in up front if you want flexibility in your approach.

4. Responsive communications and influential ‘champions’

Due to the nature of an Agile project there will be a continual flow of changes and improvements over a period of time. You will need to establish an effective communications rhythm and cascade so that whatever the project throws at you; good, bad or ugly, you’ll be able to quickly get the key messages and information out to the affected people in an efficient and controlled way.  Take the time to agree who the reviewers and approvers are to save valuable time later when responsive messaging is needed.

This is where your change champions will be worth their weight in gold. Unlike a traditional project change plan, they need to be involved and inspired right from the start. They must understand the twists and turns the project may take, be able to deal with ambiguity and challenge the project team when needed to focus on the highest value developments.  In our experience, Agile projects benefit from champions who are more senior / influential than on traditional change projects. A stakeholder mapping exercise is worthwhile to inform your choice of champions.

Remember it’s a two way relationship. Champions are able to translate the latest news and information into the best format for their teams, making sense of the change within the broader business context locally. But, they also provide a sense check, and on behalf of their teams – validate the priority of changes.

5. Transfer ownership to the business

Our experience tells us time and again, that business ownership of the solution is key to adoption. This starts right from the requirements-gathering stage, and it’s critical to keep business stakeholders on the journey through its twists and turns, through to delivery of the solution.

Business engagement takes time, and it can be seen as a distraction to delivery. However, investing the time to truly bring stakeholders on the journey will pay back in the end – reducing surprises and the risk the solution is not accepted.

The change manager must take the opportunity that Agile allows by giving users early sight of design plans, development and by performing business validations, to build trust in the solution.

It is a balance of course and we’re not suggesting bringing champions and other business users into daily stand up and scrum meetings, but formalising the ‘show and tell’ of both design plans and the solution as it’s developed means you’ll get feedback early on and then a period of validation where the business can get familiar with the solution, check the data, and start to understand the functionality.

All this serves to build trust in the project – a pre-requisite to usage and adoption.

At Afiniti, we regularly work with clients, building their change management capability and integrating with their Agile projects.  If this is a topic you’ve been thinking about recently and you’d like some advice on how to get started integrating change into your Agile projects, or how to set your Agile projects up for success, get in touch and we would be happy to discuss this further.