Agile for Change Managers – Ultimate Guide

Agile for Change Managers – Ultimate Guide


The Ultimate Guide to Agile for Change Managers







So agile has been all the rage for a number of years. Most organizations are implementing some form of agile methodology in how they manage initiatives, anywhere from the waterfall project methodology on one extreme end through to the pure agile project methodology on the other end. Yes, we know that agile may not be for every organization. Projects where the output of the change is known clearly upfront and where requirements won’t change much throughout the project may not benefit from an agile approach. On the other hand, those projects where the end design is not known, where innovation would be valued, would definitely benefit from an agile approach.


There are plenty of resources available for project managers on the mechanics of agile methodology. However, the same cannot be said for change managers. Many even comment that the role of change management has ‘disappeared’ within the agile approach. There are lots of examples of projects where there is significant change impact on employees and customers, where there is no change manager on the project.


What is the role of change managers in an agile project? How will change work be modified to suit agile methodology? How does the change manager create value in an agile environment? This guide aims to answer these questions and provide a simple and practical guide to aid the work of change managers in an agile environment. While the guide will not aim to cover anything and everything to do with agile, it will aim to call out aspects the change manager needs to consider in carrying out change work in an agile environment.


Read more about how change management principles are foundational to agile.


Let’s start with the basics of agile – the Agile Manifesto principles


When the agile ‘godfathers’ got together to come up with agile change principles all those years ago, they were quite certain that they wanted to focus more on principles than ‘methodology’ per se. Since then the intent may have changed in how organizations have adopted this. Nevertheless, it is important to visit the core of what agile stands for.


These are the 12 principles of the Agile Manifesto (from



  1. Our highest priority is to satisfy the customer through early and continuous delivery
    of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
    preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  8. Continuous attention to technical excellence and good design enhances agility.
  9. Simplicity–the art of maximizing the amount of work not done–is essential.
  10. The best architectures, requirements, and designs emerge from self-organizing teams.
  11. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.


Here are some key takeaways that the change manager should note about the agile manifesto, the core of what agile is trying to achieve:



Iterative change


Iterative change is more effective than big bang change. This is because it reduces the risk of failure and increases the chances of success. This is also how designers work – making incremental changes to ultimately come up with the right outcome. This is because with these techniques the project team is getting feedback throughout the process. Therefore, the ‘test and learn’ and prototypes in design thinking are critical as a part of an agile approach. The emphasis on constant change is the core of agile.


Multi-disciplinary team


The power of the smallish and multi-disciplinary team. Business, technical and specialists from other disciplines are encouraged to work together to come up with innovative solutions to address the problem. Each discipline may approach the same problem differently, and therefore when we put people with different approaches together we start to get innovative ideas. Smallish teams also tend to perform better in getting traction and delivering without getting bogged down by hierarchy. Most agile experts agree that the right size for agile teams would be 6-7 people.


Early and continuous engagement


Another part of what is essential to agile is designing early and continuous engagement. Business representatives are included in the project from the beginning and continue to have strong involvement throughout the process. This is particularly important as the solution being developed by the project team continues to evolve and change throughout a short period of time.


Key agile methodology terms and approaches


There are two main agile approaches that are popular in project management, scrum and kanban. A lot of organizations also use a combination of both scrum and Kanban. Let’s go through these to get a better understanding of what they are and how change fits into these methodologies.




Scrum is probably the most popular agile methodology used by project teams that are implementing agile. It starts with feedback or input from end users or customers on what the need is and the business requirements. These are then captured, analysed and defined into clear features. They can also be in the form of ‘user stories’ that outline what the user goes through in the entire process. User stories are simple descriptions of a feature told from the perspective of the person who desires the capability. User stories are usually captured in post-it notes on a board (or digitally) to allow visualization of the journey/process.


The project team then goes through a series of ‘sprints’ where iterative work outputs are created under each sprint. Each sprint is aimed to produce a discrete piece of work output that is tangible and can be used or tested in some form. Each sprint goes for 1-4 weeks and is managed by the scrum master who’s role is to do anything that optimises the team’s performance. This is not a manager role who is tasked to ‘approve’ or ‘sign off’ on the work of the team, but more of an enabler and facilitator. In an agile team, the team is self-managed and empowered to come up with unique ideas to form the ultimate solution to address the user/customer needs.




So what is the role of the change manager in scrum? The role of a change manager does not really change significantly in an agile setting. Yes, the change manager needs to understand the why and how an agile team works. However, the fundamentals of the value of change management stay the same. If a project is creating change impacts on the user or the customer, then this is where the change manager steps in. This is not dissimilar to other non-agile project settings.


Let’s dissect the work of the change manager to better understand his/her role in a greater level of detail:



Initial scoping


When we have a high level of understanding of what the project is and what it is trying to accomplish, the change manager would help to scope and size the amount of change impact in concern, the level of complexity involved, and come up with a high level estimation of how much change management support would be needed on this project. This does not change in an agile project, compared to waterfall projects.



High-level change approach


After the features have been identified and the product owner has a clear idea of what the change is and what it involves then it is time to start on devising the high-level change approach. At this stage, we still do not know exactly what the solution is, though we have a few likely options to consider. Through taking a few assumptions we can devise a high-level view of what change approach would work. A key part of this approach would involve understanding which stakeholders will be impacted.


Agile projects are focused on producing output and solutions and there is significantly less focus on documentation. However, this is not to say that documentation is not required. Instead, documentation tends to be more summarised and slimmed down versus the significant longer documentation required under waterfall methodology. In this phase, the two key documents are the high-level change approach and high-level change impact assessment document. Some even use a ‘change on a page’ similar to a ‘plan on a page’. The high-level change impact assessment could also be a one-pager that calls out key stakeholder groups impacted and the nature of the impacts.



Design and planning phase


When we get to the design and planning phase of the project the key focus starts to shift into detailed articulation of what the change is. In this phase, the approach in change work is again no different than under waterfall. However, the difference is that there may be more unknowns as the solution is being developed and shaped iteratively and continues to evolve over each iteration or sprint.


The change manager needs to determine when there is sufficient information to start to work on the detailed change impact assessment. And this impact assessment will undoubtedly need to be reviewed and potentially updated as the solution changes. Other key deliverables such as stakeholder matrix, engagement and communication plan, change plan (including measurement) and risk assessment should also be captured, depending on the level of change complexity.


The role of the change manager is to partner closely with the team to flesh out and define what the change is and what the change approach is throughout each sprint. Some may call out that this may sound quite messy since with each iteration the change approach could change. In practice, a lot of the impacts and change approach are fleshed out and captured before or during the sprint planning. With each scrum and iteration, the solution becomes more and more defined, and only tweaking would be needed on the change approach.


Early and continuous engagement is a key agile principle and therefore the change manager has a critical role to play in engaging the various stakeholder groups. Depending on the nature of the change, business and stakeholder engagement may need to occur prior and during each iteration. For example, business stakeholders may need to engaged on what the new system is, and how/what it will do for them, and how they will be impacted. Then, when we are closer to having developed a full solution with system screens being defined, we can show our frontline employees what the system looks like. Throughout the iteration process, subject matter experts and business representations, and even change champions groups have critical roles to play in providing valuable business feedback.


Another key agile principle is focused on getting end user or end customer feedback early, and continuously throughout the development process. The change manager needs to work with the business to carefully the right end users to provide feedback (versus managers who may not know the intimate details of business requirements). The change manager also needs to balance the needs to the business in being engaged on the what/why/how of the change early on, and incorporate more details of the solution throughout the iterative process.



Implementation and post-implementation


Since agile produces change at a faster pace than waterfall approaches, there are a few things that the change manager needs to adapt to. One of the key challenges for the change manager within an agile team is not to lose sight of the fundamentals of managing change. Within the series of iterations, keeping the business engaged and involved is key. On top of this, understanding and agreeing with the business the most optimal go-live and implementation period would is critical. Just because the change is ready technically, it does not mean this is the right time for the business to accept the change. On the other hand, there could be complexity or technical challenges that delay the anticipated go-live (like most projects, in any methodology). This needs to be managed effectively and there needs to be clear identification of the next ‘window for change’ from the business perspective from the perspective of the business having the capacity to digest the change.


Some propose that the change manager should ‘adopt’ agile way of implementing ‘test and learn’ in implementing change. Whilst this is valid there are a few considerations. Implementing agile does not mean that how our employees respond to change will suddenly change. From previous experiences in implementing changes, the change manager should leverage what has or has not worked and not start from zero. For example, how was the reception from a particular business unit to online learning of new products? What has worked well in terms of how this group was engaged previously? If there is little experience in change within a particular part of the organization, then it makes sense to conduct pilots to test. However, again, leverage from previous experiences where possible before starting ‘new’ tests.


Post implementation and benefit realisation are still applicable from the perspective of the change manager. Planning for effective embedment and measurement of change and that the benefits are realized through the users adopting the right behaviours are still valid under agile.


Read about the 5 things Eames taught me about agile project delivery.






Kanban is a simple agile methodology that was developed from a manufacturing background (i.e. Toyota). It is not time-based, unlike Scrum. Instead, it is based on ordering a set of prioritised activities through the funnel of ‘To do’, ‘Doing’ through to ‘Done’. The list of activities is prioritised meaning that after one task is completed and moved to ‘Done’ the next activity on the list may be undertaken. This overall list of activities can be seen as a ‘backlog’ where a set of activities have been determined to be necessary to complete the project.


This kanban board needs to be real time and constantly updated so that the team members can easily visualize the progress they are making and how much work is outstanding. This is a great way of understanding the pace of execution and output achieved. The cycle time of measuring how long it takes tasks to move from ‘To Do’ to ‘Done’ helps to forecast the delivery of future work. The kanban board acts as the single source of truth for the agile team.





All of the previous comments regarding scrum and implications on the work of the change manager apply to kanban as well. The change manager, working along-side other agile team members, would also need to adapt to the faster pace of change, and work within the team to identify any obstacles to the overall workflow. Change management work activities would also contribute to the overall kanban board and flow through this process.



Building the change environment for agile


There are significant opportunities for the change manager to add value in creating the right change environment for agile initiatives to land successfully. Some of these include:



  • Helping business leaders, including sponsors and business owners to understand their role in leading change within an agile setting
  • Support the design and dynamics of the agile team to really flourish, to generate innovative ideas and to leverage diversity of thought
  • Work with business stakeholders to prepare them for iterative agile changes where the end state is not always clear from the beginning. The challenge of crafting a clear vision of change without the necessary details
  • Helping to build the overall culture of the organization in adopting agile principles, itself a separate cultural change exercise. For organizations that are risk-averse the challenge may be to instill the value of ‘safe to fail’



The ultimate dilemma for the change manager


One of the ultimate challenges of preparing the organization for an agile environment is to understand the environment itself. When there are numerous agile projects going on in organizations, each with continuous iterative change, there lies the challenge. How does the business get visibility of all of these chunk-sized changes and be able to prepare for them collectively? Without a clear oversight of a collection of changes that are constantly moving it is almost impossible to effectively lead and embed changes effectively.





The solution is to adopt agile principles in preparing the organization for multiple agile changes. Think – visualization, measurement, reporting, collaboration, flow, and continuous delivery. The change manager needs to support the view of change by working with agile teams to make visible the changes being planned for at any given time. One set of changes from one project may seem simple enough to articulate. With multiple projects, this starts to become complex and difficult to make clear to business stakeholders. Without clarity and understanding, it is hard to be ready for change.


With the right data on what is changing, when, to what parts of the organization, the change manager or business leader can better plan for change. This insight can be utilised to better empower the business to understand their own change capability at a given point in time. On the other hand, this also helps the agile project teams to better understand what other changes are being released into the business. This collaborative sharing of information helps with planning across projects. For example, if a project is going to be delayed in its release, a clear visualization of the change slate within the business can help with identifying other time slots where the runway is clearer for the business to better digest the change.


Read more about how to manage a peak change period resulting from Agile.


Examples of visualization of change impact data from The Change Compass



In the new and exciting world of agile there are those who trumpet the end of change management as change roles are not specifically called out in agile methodologies. However, it is quite the contrary as outlined in this guide. The challenge for the change manager is not only to understand agile and find his/her place in this approach but also to add additional value by helping the organization to deal with all the various impacts of agile. These include cultural, leadership, ways of working, roles and responsibilities, process and operational planning perspectives. This could be lead to the next phase of development for change management.


Read our ultimate guide to change portfolio management.




If you like this post please share this with your contacts




The secret in motivating change

The secret in motivating change

Move over older concepts and frameworks such as Lewin’s, Bridges and Lubler Ross models that are dated and not based on years of rigorous research…..

It’s time we started to focus on well-researched and evidence-backed models that explain people’s behaviours in change.

Click here to download the infographic on ‘Self-Determination Theory’ of motivation. Stay tuned for our up-coming article on this.

Use this agile technique little known in change management to get the best outcomes

Use this agile technique little known in change management to get the best outcomes

The MoSCoW technique of prioritising initiative requirements or features

The MoSCoW method of prioritization is well used by Business Analysts, Project Managers and Software Developers. The focus is on identifying and agreeing with key stakeholders what are the core levels of requirements that should be focused on more than others. This process of prioritization will then enable a better outcome in focusing the efforts of the team on the most important aspects of the solution given limited time and cost.

MoSCoW stands for: Must Have, Should Have, and Could Have.

There is significant opportunity for change practitioners to also adopt this technique to better prioritise a range of different change interventions. Too often, change activities are planned as a result of stakeholder requests, and not necessarily as a result of a prioritized approach of what approaches/activities provides the best outcome versus others.

1. Must Haves:

These are core, fundamental requirements that must be there for the end outcome to be there. These are the non-negotiable ones without which the goals of the project cannot be achieved.

For example, in implementing a new system, the users must know that the system is going to replace the previous system and the reason for this. Users must also know how to operate the new system prior to the older system being switched off.

2. Should Haves:

These are features or requirements that would have a high priority to reach the project outcome. These can often be core features that will add to the user/customer experience. However, they are not a must, and given challenges in time or cost they can be deprioritized.

For example, for a new system implementation it would be highly desirable to allow the users to access a sandbox to be able to play with the features prior to the launch to improve their readiness. It could also be that due to the large number of users using the system it makes sense to conduct a large scale awareness campaign to broadcast the arrival of the new system.

3. Could Haves:

These are nice to haves given sufficient resources such as time and cost. These requirements are definitely not critical and can easily be deprioritized as needed.

For example, in implementing the new system it may be nice to have coaching workshops with users prior to the go-live to offer additional learning support for those who may need more help. It could also be various system support materials such as cheat sheets, booklets, etc. to help the user embed the ins and outs of using the new system.

4. Won’t Haves (or Would Haves):

These are potential features or requirements that may be looked at in the future if there is sufficient resources available. This is the lowest in the order of priority, meaning that it will not make significant impact to the outcome of the project.

For example, in implementing the new system refresh training sessions could be offered later down the line for some users after go live. Depending on the organization and previous experiences an ‘embedment campaign’ could also be scheduled to drive continual usage of the system. But given the cost required these are deemed lowest in the priority.

In prioritizing change management approaches and interventions this way, we are adopting a structured method of determining the activities we are investing in to get the right outcome. The clarity of which interventions are core and foundational, versus others that are desirable or nice to haves is important to the success of the initiative. This could also avoid any disagreements or questioning of the change approach further down the line as the approach follows a structured and agreed process with stakeholders.

Practical agile for change managers – Part 1

Practical agile for change managers – Part 1


A critical part of agile is being able to iterate and continuously improve in order to deliver an optimal solution. Rather than one large change release, an agile project would break this down into smaller releases. Each release will go through an iterative process to test, collect data, evaluate and use any learning to improve the next release.

If an agile approach is appropriate we should also adopt this same approach in how we deliver change management activities. This means that we should be running a series of experiments to test, learn, document and improve on how we deliver change to the organization.

This contrasts to how most change managers would approach developing and delivering the change approach. The standard approach is collecting various information about the change, talk to key stakeholders about the change, and then form a view based on previous experiences in terms of what change approach would work for this initiative. Then, this approach would be present to stakeholders to get their blessing before executing on the change approach.

Below is an example of planning to run experiments in an agile environment from Alex Osterwalder, the founder of Strategyzer. First is designing the experiment, shaping its hypothesis, and testing it, which involves looking at the outcome data, learning from the experiment and making any relevant decisions based on the outcome.

Referenced from Alexander Osterwalder.

In this first part of a series on practical agile applications for change managers we focus on communications.

Communicating for change is a critical part of managing change and is also one that can easily be tested using a series of experiments.

The Campaign Monitor has outlined a series of aspects in which emails can easily be tested. These include:

  • Subject headlines
  • Pre-header
  • Date and time
  • Call to action
  • Content

Digital businesses also often conduct A/B Testing whereby 2 different sets of content are designed and delivered at the same time for the duration of the test. At the conclusion of the experiment we can then look at the results to see which one did better based on audience responses.

How do we measure communications experiments?

There are several ways to do this:

  • Readership – For intranet pages, your corporate affairs rep can usually access readership statistics
  • Surveys – Send surveys to the audience to ask for feedback
  • Focus groups – Run small focus groups for feedback

There is one area in which corporate can better learn from digital businesses – using digital tools to measure and track communications. For example, you can send out emails promoting a new intranet page, and then check back to see how many users actually visited the site. The results may be helpful as an initial experiment before launching the email to a wider audience group to achieve maximum results.

There are plenty of external tools such as ActiveCampaign or Mailchimp where you are able to use features such as:

  • A/B testing results
  • Send emails are certain times or dates
  • Automatic email responses
  • Target particular segments
  • View and click rates

In the following diagram you can see an example that it’s not difficult to build a drip-email series of interactions with your stakeholders based on their responses (or lack of).



It’s feasible to use these tools for a project where you can run a series of experiments and measure outcomes to support your change iterations.

Want to read more about agile? Visit our Ultimate Guide to Agile for Change Managers.

I discovered these 5 surprises in managing an agile digital project

I discovered these 5 surprises in managing an agile digital project

As someone who is normally overseeing the change management side of large programs and portfolios, I now find myself being in the shoes of a project manager. Here’s the background. I now manage a digital software-as-a-service business (The Change Compass) aimed at those who are driving multiple changes in their organizations. In terms of managing change deliverables and stakeholders, I was perfectly comfortable, having done this with some of the largest organizations in the world. However, I was not trained as a project manager, and particularly not in managing a digital product.

Having worked on very large digital projects over the years I‘m familiar with the different phases of the project lifecycle and lean/agile/scaled agile methodologies. However, managing a digital project hands-on has revealed some very surprising learnings for me. I will share this in the following.

  1. The customer/user doesn’t always know best

Over the years we have received quite a lot of customer feedback about what worked and what didn’t work and we have iteratively morphed the application inline with customer wishes. However, a ‘customer/user suggestion or wish’ is not always the best for them.

There are some features that we have developed to enable the user to build different reports. However, after lots of feedback, and iterations, we’ve found that the users actually don’t use these features much at all. On the other hand, there are other features designed based on our observations of how users have behaved that are very frequently used. In the design phase, some users have commented that they are not sure if these features will work. However, after trialing these they have easily adopted these and have not made any suggestions or comments since.

It is probably similar to when the first iPhone was released. A lot of people were negative about how it did not have a keyboard and that the lack of tactile pressing of buttons was a sure sign that it was not going to work. Did Apple derive iPhone purely based on customer feedback? Did customers already know what they wanted and simply told Apple? Nope. Well, the screen-only mobile phone with no or limited buttons is now a standard across mobile phone design.

To read more about avoiding key gaps in managing customer experience click here.

  1. Setting clear expectations is absolutely critical

At The Change Compass we have a very diverse and scattered team. We have our development team in India, a UX designer in Canada, graphic designer in Europe and Analysts in Australia. Most of our team members are quite familiar with agile practices. They are familiar with each phase of the agile life cycle, Kanban boards, iterating releases, etc. For our Ultimate Guide to Agile for Change Managers click here.

However, one big lesson I learnt was the importance of setting clear and mutually agreed to work deliverables. With such a diverse team composition comes diverse understanding of the same concept. In agile, we try not to over-document and rely on discussions and ongoing engagement to achieve collaboration and clarity.

However, what I learnt was that clear documentation is absolutely critical to ensure that there is crystal clear understanding of the scope, what each deliverable looks like, what quality processes are in place to reach the outcome, the dependencies across different pieces of work, and what each person is accountable and not accountable for. All of these sound like common sense. However, the point is that it is common for agile projects to err on the side of too light in documentation, therefore leading to frustrations, confusion and lack of outcome achievement. In our experience, documentation is critical.

3. Boil everything down to its most basic meaning

In digital projects there is a lot of technical jargon with backend, front end, and mid layer design elements. Like any technology project, there seems to be a natural inclination to become overwhelmed with what is the best technical solution. Since I did not have a technology background I forced myself to become very quickly familiar with the various technical jargons in delivery to try to compensate.

However, what I found was that with such a diverse team, even within the technical team there is often misunderstanding about what a technical term means. On top of this, we have other non-technical team members such as Analysts, UX designer and Graphic Designer. We have experienced lots of team miscommunications and frustrations as a result of too much technical language.

To ensure the whole team is clear on what we are working on, how we are approaching it, and their roles in this along the way, we’ve tried hard to ‘dumb down’ the use of technical jargon into basic language as much as possible. Yes – there is a basic set of digital language necessary for delivery that all members should understand. But, beyond this we’ve tried to keep things very simple to keep everyone on the same page. And the same can also be applied to non-technical language, for example, graphic design technical terms that the techies may not be able to understand can also cause misunderstanding.

  1. Team dynamics is still key …. Yes, even in a digital project

To get on the agile bandwagon a lot of project practitioners invest deeply to undergo

various training to become more familiar with how agile projects are conducted. While this is critical what I’ve found is that no matter what project methodology, agile or non-agile, digital or non-digital, the basics still remain that effective team dynamics is key to a high performing project team.

Most of the issues we have faced is around team communications, shared understanding, how different team members work with each other, and of course cross-cultural perceptions and behaviours. Any effort we have placed in discussing and resolving team dynamics and behaviours have always led to improved work performance.

  1. The struggle of releasing something that isn’t perfect is hard

Being a typical corporate guy having worked in various large corporate multinationals it is ingrained in me that quality assurance and risk management are key to any work outcome. Quality work is one that ticks all boxes with no flaws and that does not expose any risks to the company. In the typical corporate world, any flaws are to be avoided. Thorough research,, analysis and testing are required to ensure the quality is optimal.

The agile approach challenges this notion head on. The assumption is that it is not possible to know exactly what the customer or user reaction is going to be. Therefore, it makes sense to start with a minimum viable product, and iterate continuously to improve, leveraging ongoing customer feedback. In this approach, it is expected that what is released will not be perfect and cannot be perfect. The aim is to have something that is usable first. Then, work to gradually perfect it.

Whilst in theory it makes sense, I’ve personally found it very difficult not to try and tick all boxes before releasing something to the customer. There are potentially hundreds of features or designs that could be incorporated to make the overall experience better. We all know that creating a fantastic customer experience is important. Yet, an agile approach refrains from aiming to perfect the customer experience too much, instead, relying on continuous improvement.

Learn how The Change Compass deliver results in managing complex, multiple changes.

See how The Change Compass helps you achieve insights, improve stakeholder ownership, through data visualization

You have Successfully Subscribed!