Agile methodology is fast becoming the ‘norm’ when it comes to project methodology. There are strong benefits promised of faster development time, ability to morph with changing requirements, less time required to implement the solution, and better ability to meet project objectives. There aren’t too many organisations that do not use some form of agile project methodology in how they manage initiatives.
What started out as a way of developing software, has evolved into the accepted methodology for managing projects. A scan of literature available on the internet shows significant outline of the various roles and their importance in the agile project methodology process. Most roles are clearly outlined and accounted for. There are clear roles established for the business owner, the project manager, the scrum master, developers, testing and quality, product manager, architect, human-centred designer, and even IT operations.
However, there is a glaring gap. What about the role of the change manager?
A review of literature available through project management organisations such as APMG (Association of Project Management) and PMI (Project Management Institute) showed glaring omission of the role of the change manager or change management practitioners from agile methodology. The same is also true for Scaled Agile Frameworks where there is a brief mention of the importance of change management in the agile approach, but no mention of the role of the change manager/practitioner.
Is it that there are less projects requiring change managers?
The evidence is against this hypothesis. Jobs in change management are plentiful, with data on ‘Indeed’ online employment portals pulling up over 38,000 job postings. On top of this, there is an increasing number of jobs posted. According to the U.S. Bureau of Labor Statistics, “management analytics” which includes change management, is projected to have a 14% growth rate between 2018 and 2028. In Australia, the ‘Seek’ employment platform projected change management job growth to be at 15% growth in the next 5 years.
Is it that agile methodology is more for technical projects and therefore the omission of change managers?
The agile approach can be used for a range of different projects, but not all projects. There is certainly evidence of agile project methodology used in a wide range of industries from financial services, government, non-profit, pharmaceuticals, utilities, and retail industries. The agile methodology is commonly cited for being better for projects where the outcome is not clearly known and where the end change has a level of uniqueness.
However, it is not true that agile methodology is only used for more technical projects. Even for projects where the focus is not on technical development, agile approaches are used widely. Agile changes have been used for re-organisation exercises. Here is an example from the Business Agility Institute. Executive teams also use agile means to manage various strategic initiatives that are not technical. Agile approaches are even applied to managing church initiatives.
What is the likely reason for the clear omission of change management in the agile methodology?
It is likely that those in charge of documenting agile methodology haven’t figured out how to incorporate change management into their frameworks.
Organisations in charge of documenting agile methodology are mainly focused on project management and software development. If we take the examples of PMI and APMG, both are project management associations, and both are focused on the project management perspectives of agile. The portion on change management is a specialism of project management. It could be that these organisations have not sufficiently developed agile change management methodology to integrate with agile project management.
Even at Scaled Agile, which is about applying agile across the organisation, the omission of the role of change managers is still the case. Frameworks from Scaled Agile are quite detailed and rigorous. All aspects of the roles of various organisational members are clearly outlined. Even the role of IT departments in DevOps are clearly spelled out to support agile. But not the role of change managers. Again, this could be due to those at Scaled Agile not having a change management background, and therefore not being able to articulate the various role detail.
However, there are some very critical roles that change practitioners play not only at project level, but at program, epic, and organisational levels. Without the right change management support the following are key risks when organisations are working at SaFe (scaled agile) level:
Change sequencing to maximise adoption across the change portfolio
Packaging change to achieve optimal change adoption, e.g. in terms of integrating communications and learning interventions across projects
Establishing business unit based change champions that can support multiple projects and can help piece together different changes for impacted employees
Identify and manage potential change saturation and change fatigue
There are some attempts at closing the gap to document agile change management approaches. However, most are conceptual, high level, and not sufficiently detailed to provide clear guidance and practical application for the change practitioner. On the other hand, the work of change management in agile projects should not only be clear for the change practitioner but also be clear for the project manager and other project members.
What’s the problem of omitting the role of change managers from agile methodologies?
1. The role of change management could easily be omitted. Particularly for less experienced project managers who are starting out in agile. The risk could be that change management is omitted from the project altogether since it is not called out as a clear role
2. Change practitioners are not clear with the roles they play and therefore are not sufficiently involved in driving and supporting the project in the right way. Since there is not a clear set of guidelines and methodology for change practitioners, it is common to see varying approaches in how change managers support agile projects. Some still use a similar approach as to supporting waterfall projects which may not be appropriate.
3. Agile projects are not successful because change management work is not sufficiently incorporated. With change management roles not spelt out, the project executes the change without critical change management foundations and therefore is at the risk of not achieving the adoption and benefit realisation targeted.
What should we do about this?
1. Encourage change management associations such as CMI and ACMP to invest in detailing agile change management methodology in a way that sets standards and guidelines for change practitioners to follow.
2. Influence and work with APMG, PMI and Scaled Agile to include explicitly the role of change managers and agile change management methodology.
Change management is emerging to be a strong discipline that executives are starting to recognise as critical to successful change. The role of change practitioners should be stated explicitly and recognised clearly. Change managers should not have to tip-toe in maneuvering their place in supporting agile change projects, nor should they need to convince other project team members of their place throughout various agile routines and methodology phases. It is now time for the change community to drive this and achieve the recognition that it deserves.
Delivering constant changes is a requirement in implementing agile change management. With each iteration, a change is being designed and released as a part of ongoing agile development and project implementation. However, there is little mention in change management literature of how to go about delivering change constantly and be able to achieve optimum change adoption.
Continuous delivery pipeline
The concept of a ‘continuous delivery pipeline’ is a core part of the agile methodology. It refers to having a structured pipeline of continuous changes being released as required by the organisation. The pipeline contains a set of features and changes to be worked on, and the resulting prioritised changes are released when and as needed.
The three components of a continuous delivery pipeline that forms an agile release train include:
Continuous exploration – This is about defining and scoping what needs to be built using human centred design approaches to design the problem that needs to be solved from the user perspective
Continuous integration – This step involves taking those prioritised features from the backlog and investigating further to understand what development work is required to turn them into solutions for the user.
Continuous deployment – This is about turning the completed changes from the staging environment into production, meaning the live product that is ready to be used by the user. After the technical part of the solution is ready to be released, the business then determines when is a good time for this release to go ahead.
The ‘technical side’ of the agile team is fairly well defined in terms of the roles and responsibilities of each member, including project manager, developer, QA/testing, business analyst, business owner, etc. However, the role of the change manager is much less defined and black and white. This does not mean that there is no role for the change manager though. It just means that the agile literature has not well defined the details for the role of the change manager in an agile team. ‘Agile change management’ still has some work to do to make itself better known to other agile team members.
So how does the change manager get ready to deliver a series of constant changes?
Delivering a series of constant changes is no easy feat. The main issue is that most businesses are not designed to face multiple changes, and nor are they designed to face a series of continual changes either.
Change approaches are primarily written for working on one change at a time, and not in a setting where there are continual releases of changes going on. On the other hand, how many organisations do you know that are only facing one change? Or that only deals with one change within a month? This type of stable change environment may have been the norm years ago when the business environment was much more predictable and stable. Hence, using a waterfall project approach was appropriate at the time. Fast-forwarding to the 2020s most organisations are juggling with constant and multiple changes as the norm.
1. Derive a picture of the changes within the continuous delivery pipeline.
Deriving a clear picture of what changes look like within a project is critical. Without this, you will not be able to clearly communicate to your stakeholders what changes are coming down the pipeline.
To create this picture, use a human-centred approach and illustrate what the user will go through throughout the change journey. This is similar to a user journey map. However, a change-focused picture goes beyond just what the user will be going through. It also includes not just person-based changes, but also process, policy, system, governance, reporting and other changes. Outlining these changes will complete the whole picture of what each change release may look like.
A key problem in creating a picture of the changes early on is that the project team may not even know what the solution looks like. And without particular details of every change release and solution design, it may be hard to create this picture.
The recommended approach is to focus on what the outcome could look like versus focusing on various technical or process solutions. This means you may even need to make particular assumptions in defining what these changes look like. For example:
Release 1: Ability to turn recorded customer conversations into text. With this feature, there will be new risk and privacy processes and governance be put in place in the monitoring and storage of customer data.
Release 2: Ability to search for customer conversation history and flag follow up actions required. Specialist roles may be required to audit customer conversation text. Behaviour shifts in proactively checking on customer history and knowing what to look for in trends is critical.
Release 3: Ability to use analytics to predict customer turnover and use this to minimise customer turnover. Significant capability uplift is required to ensure that consultants are able to know how to use analytics to help minimise customer turnover. Analytics capability uplift is also required at operations management, supervisor and team leader levels.
2. Map holistic stakeholder impacts.
In order to implement constant ongoing changes, it is critical to understand holistically what the stakeholders are undergoing across all types of changes and other BAU impacts. Without taking these into account it is not possible to truly understand the capacity of stakeholders and when changes will best ‘stick’ when released.
Some of the items that should be inventoried and mapped include:
Impacts from the current project that you are working on
Other project impacts that affect the stakeholder at the same time as your project, including any benefit realization periods post project implementation
BAU-led initiatives that could include business improvement or quality, and may not classified as ‘funded projects’ per se
Key high work volume periods such as end of financial year, holiday season, etc.
Audits, planning or reviews where additional work volumes are forecasted
It does take investment and effort to collect all these types of data and most change managers do not bother to do this. However, it is not possible to implement a successful change when you do not understand what other changes or work priorities your stakeholders are undergoing during the change process.
It is also important to note that this type of impact data can change constantly and once the data is collected it needs to be verified on a timely basis with any changes and updates reflected over time. Doing this activity manually can be quite cumbersome so we advise using digital tools such as The Change Compass.
The collected data on what stakeholders are undergoing can be significantly valuable. Often stakeholders themselves have not undertaken this exercise to truly understand the change journeys and work priorities added together holistically. They may be surprised by the picture you are presenting to them. At the minimum, they will value this since it shows that you have a deep understanding of what they will be going through and therefore create more stakeholder confidence.
3. Sizing and categorising the impacts of changes
After getting a clear picture of holistic change environment that the stakeholders will be undergoing the next step is to analyse the impacts from your project. In analysing the change impacts you should be ascertaining the nature of these change impacts including:
Size of the impact
How long the impacts will last
How much time these impacts translate to
Types of these impacts (e.g. people, process, system, customer, etc.)
To whom the impacts will be on
Quantitatively sizing your impacts makes them concrete and easily understood. Armed with this information you are able to examine to what extent the planned releases are the right ‘size’ for the impacted stakeholder groups. This is another critical part of agile change management. In determining this, the following stakeholder factors are critical:
Potential overlaps across various impacts either within the same or with other projects or initiatives
Change maturity level and experience with similar changes in the past
Leadership support and other change reinforcement mechanisms
Overall change readiness
Engagement level with the particular change initiative
When you have considered all of these factors you are ready to engage with your project manager, the PMO, and business representatives to assess to what extent the roadmap laid out is effective and will work to maximise the targeted initiative benefits.
4. Business operations routines
Now you understand clearly the change environment of your impacted stakeholders, various changes within yours’ and other initiatives, and the categories of the various change impacts. The next step is to clarify to what extent your impacted business units have the right operational process to receive ongoing changes. This is often a neglected part of agile change management.
More change mature business units have over time developed the right routines and processes to absorb changes, especially ongoing ones. What are some of these?
Effective engagement processes. Engagement processes are not just one-way communication channels. Having effective communications channels such as newsletters and town halls are a minimum for employees to hear about what is coming down the pipeline. Engagement processes include such as effectively choreographed Yammer channels, skip-level meetings (where managers meet with employees 2 levels down), focus group sessions with a small group of select employees, and effective team meetings where information is passed both up and down the chain of command
Effective learning processes. Effective learning processes at a business unit level includes business operations routines whereby employees have individual development plans (from which training plans can be incorporated), ongoing monitoring of development tracking against targets (e.g. completion rates), virtual learning processes (e.g. employee familiarity with virtual ways of self-initiated learning)
Change champion network. Most change champion networks are project-based and therefore have a limited shelf-life. This means that business change champions have a limited time to learn and develop as effective change champions. They also have limited time to practice and experience what it is like to lead and support change. A better design for business units undergoing ongoing changes is to have business unit based change champions that can support a myriad of changes across the board. This flexes their capability. Also, with constant exposure to changes over time, they are able to continuously develop and become better change champions. Organisations that have done this well, have positioned this as a ‘talent pool’ for frontline employees seeking to grow into other challenging roles.
Benefit realisation processes. Tracking and reinforcing benefit realisation is one of the most critical ingredients for success in the impacted business unit. Usually a month after go-live, the project would have already wrapped up and the business is left to continue the rest of the change journey and achieve the targeted benefits. To do this the business unit needs to have clear benefit realisation tracking and reinforcing mechanisms, involving Finance and business leaders. There needs to be constant oversight of how the benefit tracking is trending and leader discussions on resolving any obstacles and providing adequate managerial support to drive the benefit realisation process.
If your impacted business unit lacks one or more of these ingredients, it is critical that you work on this upfront. Highlight to business leaders the risk of not having these ingredients in place within the business. These processes may take significant time and investment to build up. Therefore, factor in the time required to develop these. Often, within the challenges of agile changes, these are left until the end, by which time it is too late to try and establish quickly to support the identified project changes.
The increasing pressure to change and evolve continues to challenge the very existence and design of every organisation. After waves of change and disruption from industry competition, technology evolvements, customer preferences, surge in commodity prices, and Covid, change is, more than ever, a constant. To meet with this rapid and increased intensity of change, organisations are resorting to agile ways of implementing change management to keep up.
Agile ways of implementing change often times mean that the outcome may be reached faster, and sometimes with fewer resources than previously. With these promises, there are very few organisations that are not jumping along the agile bandwagon.
So what are the challenges of using agile change management?
1. Agile change may not suit every change scenario
Agile ways of change management may be great when we are developing a new product, a technical solution, a new process or a new way of working. However, not every change scenario. If the change setting requires strict adherence to complex regulations and standards, significant documentation, testing and quality assurance, full agile may not be the most suitable. Pharmaceutical companies would not use a pure agile approach in developing new drugs simply due to the level of regulatory and industry standards required to be met in the process.
However, this does not mean aspects of agile practices may not be incorporated. For example, pharmaceutical companies have been incorporating practices of involving customers in product design and marketing communication. The trick is to balance those agile aspects which would benefit the overall solution and outcome, versus others that may be less applicable due to organisational and industry challenges.
On the other hand, if the project is concerned with developing changes to meet a new government regulatory requirement for customer product disclosure, an agile change approach may be more suitable. Change iterations can be designed to form the solution required to both meet regulatory requirements and not negatively impact customer experience.
2. There are significant capability requirements in implementing agile changes
Implementing agile changes does not just mean using agile techniques in the project team. Every team involved needs to be able to build up agile capabilities. This includes not just the technical teams, quality and testing teams, but also business stakeholders, and depending on the change, customer advisory teams as well.
Project teams may be used to agile techniques after several projects. However, these may be foreign for business stakeholders. Sufficient education and capability building may be required in impacted businesses to undergo the change process. This is because without this experience, the impacted businesses may not sufficiently buy-in to how the change was designed and implemented. Moreover, without adopting agile practices, the impacted business teams may not be able to adopt the changes at the rate expected in agile environments.
3. The agile methodology has not clearly specified change management elements
Agile project management methodology clearly lays out the roles of the various members of the agile team, including the project manager, business owner, quality and testing, developer, etc. However, a big hole exists for change management. The clear role for change management has been left out. For example, methodology and training providers such as Scaled Agile. In a seemingly detailed and comprehensive treatment of all parts of agile methodology, the specific details of the role for change managers are not mentioned anywhere.
To tackle this big gap, there are various attempts to try and close this gap such as Jason Little’s Agile Change Management approach that is possibly less comprehensive than those detailed by Scaled Agile.
Why is it that the role of the change manager is clearly omitted? It is not that the role of change manager is becoming obsolete. The increasing popularity of agile is matched by the increasing demand for change management professionals. There has been a consistent growth in the recruitment for change professionals year after year. It could only be that perhaps those in charge of documenting agile methodology don’t have a background in change management and subsequently have not ventured to detail any requirements within the methodology.
Imagine a world where change professionals won’t need to tip-toe and educate others about how their roles fit within an agile setting. Given the importance of change management is it not a gap that cannot continue forward? Perhaps we can garner the change community to drive this through in the 2020s?
4. Oversight of multiple agile changes is more critical than ever
One of the key challenges of using an agile approach is that often the end change outcome or the solution of the change is not clearly known at the commencement. With each iteration, agile changes become more and more defined. Or at times, the solution may continue to evolve and pilot as required according to project requirements.
What this means is that at any one-time business stakeholders are dealing with multiple projects that are constantly evolving. The impact of those projects may or may not be known depending on the development of the specific agile iterations. This could make it a nightmare to plan and get ready for multiple changes from a business unit perspective.
The solution is to develop oversight of the entire group of change initiatives. With constant oversight, the business is much more capable of preparing for change overall. And with the shifting iterations of agile across initiatives, the picture continues to evolve so that the business can keep a pulse on the changing nature of change. This includes not just the volume of impacts, but types of changes, role impacts, timing, change pace, readiness, etc. Utilise digital change management solutions to support your stakeholders as they continue down the agile change journey.
How will you support your business stakeholders as they charter through the ever-increasing environment of change and disruption? What digital tools are you adopting within this digital world to get ready for increasingly agile changes? Just like the agile principle of including and integrating multiple disciplines to promote collaboration, leveraging digital tools to aid change readiness and collaboration is key to future change outcome success.
To read more about agile change management articles visit our Knowledge Centre where we have articles such as:
It is 2022 and at the beginning of the year, we reflect on the previous year that has been. A year ago most of us were praying for the end of Covid so that we can move back to ‘normal’. One year on, here we are again. Covid disruptions are even more severe and widespread. Not only are we still amidst continuous business disruptions compared to a year ago, but probably even more severe.
We see lots of memes around social media of people wanting to forget the past year with the difficulty of life caused by Covid. And a year ago it was the same. What we are learning is that change and disruption will not be going away any time soon. The only thing we can do to support our organisations is to continue to build change agility. With better change agility, organizations are better able to respond to constant and continuous change.
The big positive for change managers is more than ever, change is now the centre of attention for businesses. In the past, many would struggle to position management conversations about the importance of managing and leading change. That is no longer the case. Even the most backward and change immature businesses are thrust in the midst of constant change. We no longer need to raise this as a topic of focus.
This means now is the opportune time to utilise the focus on change to gear up the organisation’s readiness and capability to respond to the constant change in the longer term. More than ever now is the time to pitch to your organisation about the importance of building the right ‘change agility muscles’ so that the organisations can remain competitive and in business.
What are some of the benefits of agile organisations?
We can see quite stark examples of organisations that are agile versus those that are not. Businesses that jumped on web offerings have benefited versus those that have relied purely on brick-and-mortar channels. Other businesses have diversified their offering whilst others have reduced their store footprint.
Mckinsey studies have shown that with successful agile transformations, organisations can achieve significant business improvements. Not just surviving, successful companies have achieved 30% better customer satisfaction, 30% improvement in operational performance, 5-10 times speed in driving change and decision making and ranking higher in innovation compared to peers. These organisations are also 30% better at engaging employees and 30% more efficient in their operations through fewer handovers, reduced overhead with clear focus areas.
However, as a change manager, how can I move the dial on improving my organisation’s agility for change? As a solitary individual how does one person influence an organisation? This is especially when you may not have the decision making authority nor the power? As a change manager you have your project work defined. How can you do this without boiling the ocean which may not be part of your bread-and-butter role?
These are 5 ways to improve your organisation’s agility as a change manager:
1. Influence your project sponsor and business owner to lead agility.
A part of the change manager’s role is to help influence and to equip stakeholders with the right skills to drive the change. This starts with your own project. As a project, assess the skills of your project sponsor and business owner. Do they have the experience and skills to lead agility practices as a part of overall change leadership?
These may include:
Ability to spot changing and emerging trends that may impact the organisation’s business
Balance the oversight of immediate daily operational trends and insights, against longer-term and more strategic patterns and trends that may emerge
Ability to work across disciplines in influencing change
Promotion and advocacy of constant experimentation and testing of new ideas and concepts, supporting experimental failures as they arise
Lead behaviours that support organisational learning, whether its learning from within the industry outside the industry, using historical data, or through innovation incubation teams
Savviness with shifting technological trends and use cases that could implicate the business
Work with your sponsor and business owner and help to identify key required agility leadership behaviours. Partner with them and coach as necessary to support these behaviours. Collaborate and come up with a skills development plan if necessary.
2. Embed agility practices within the implementation design of your project.
To support business agility the first step from a project perspective is to ask how the project benefits can be protected and sustained even in times of constant disruption and uncertainty. Asking this question is the first step to take. Simply asking this may help you re-shape the project’s approach in its implementation and the work involved.
Some of the ways in which you can design agility into your project include:
Designing flexible role and team structures where appropriate to ensure that any workload or role changes can be easily flexed and catered for in case of future changes
Designing the right skills and competency requirements into business roles as a part of role requirements, including agile leadership, experimentation, work approach flexibility, and reporting/data fluency
Building agile business rhythms and routines into business readiness and future end-state designs. These may include stand-ups, business scanning and review practices, and agile iteration practices
Work closely with your business representatives and subject matter experts within your project and leverage them as anchors for agility practices into the business
Leverage your pilots as agility experiments in designing agility components into your change implementation. For example, use the pilot as a test from which to build agility components so as to further change agility in the rest of the project roll out
3. Proactively participate in change centre of excellence, or if this does not exist, built a change network with other change managers and interested business representatives
Leverage the power of other change practitioners in other projects and across the business to collaborate and build a common approach to further change agility in the business. Work with others to come up with ways to influence the business and build practices that will help the business strive in times of disruption and change. Don’t underestimate the power of like-minded representatives across the business. Each representative acts as an influencing node from which powerful tactics and practices can be driven into the business.
Work across projects to build one view of change impacts. By building this integrated view of change impacts across multiple projects, you are also helping the business connect the dots and build an integrated way of getting ready for all changes, not just yours. An integrated view of change can help you:
See a holistic picture of what is going to change
Prepare the business for what is going to change across the board, and this is made easier by knowing what will be changing
Utilise the changes in the roadmap to design a series of agility tests to prepare the business for challenges further down the track in the roadmap
4. Liberalising data and support swift decision making
Historically, in hierarchical companies data is usually restricted to select managers. With digitisation there is an opportunity to give power to a much larger number of employees to access data and through this be more aware of the changing needs of the company. Liberalising data to make faster and better decisions is one of the key trends of digitisation. This is also a key enabler for change agility. With easier data access for a greater number of employees, decisions can be made by those who are most familiar with the work context, on a timely fashion. This ease of data access means that someone does not need to wait for rounds of approvals to make decisions.
This also applies to change data. Rather than restricting the access of change impact data to a select few managers, liberalising this across a larger number of managers and team leaders can help to paint a clearer picture of change and help equip the business’ readiness for change.
The ease of acess to data does not just mean the raw data itself, but ease also implies the ease of understanding the format of the data. Pre-configured data visualisation and charts are valuable since the user will not need to go through long training sessions in order to use the data. By making the data easily understood and make sense, the business can then balance forecasted change against impending change disruptions that may not be forecasted.
5. Change scenario planning
Scenario planning is an exercise where a facilitated team reviews the existing operations and the external business environment to try and forecast differing business scenarios. Scenarios are then used to build the right tracking signals. The business may have already built safeguards toward this scenario, or a clear set of next steps in which to deal with the progress toward this scenario.
Not a lot of projects conduct scenario planning, as scenario planning is typically conducted by strategy and planning functions. However, undertaking scenario planning can help build in the right rail guards to safeguard against different scenarios before they emerge.
Work with your project team and business stakeholders to undergo an annual scenario planning exercise in which to prepare the business for various environmental disruptions and challenges. Scenario planning does not need to be a long, formal, drawn-out process. It could be as simple as spending a day exploring what the future holds, having done the homework to prepare for what the data could be telling us. After identifying various scenarios, ensure you name each scenario, with a meaningful analogy if needed so that it’s more meaningful and easier to remember for the team.
You can also put in practice scenario planning on a smaller scale. Within certain junctures of the project you can build in mini-scenarios of the various change outcomes that may occur, and build in the right tracking metrics and reporting to see which scenario is emerging.
You can also use scenario planning to work through multiple changes across the projects and change landscape. Use similar concepts to work-through options in sequencing and prioritisation and what this means to change implementation timelines and tactics. For example, are there ways in which implementation may be combined across projects? Or can releases be broken down into smaller change bites to aid adoption and cater for limited business capacity?
There are many ways in which you as a singular change manager can influence and drive significant agility changes within your organisation. Here we outline 5 major ways in which you can do this. Since disruption and ongoing change is not going away, this is the opportune time for change practitioners to grab this window of opportunity and work with the business to develop and design change agile organisations. Not only will your project have a significant better chance of realising its targeted benefits, so will other projects in the pipeline.
In most agile project delivery methodologies there is a clear absence of the specific roles and deliverables of the change manager. Almost every other function is clearly outlined. Look at the work of the project manager, developers, DevOps, quality, business stakeholders, and testing. Not so for change management. This is because the agile change management methodology is not clearly developed. Some even call out that the role of change management is diminishing within agile methodology.
So what is the role that change managers play in the agile product delivery process? What are the actions, approaches, deliverables and considerations required for change professionals in an agile environment?
We will address these in this article.
What is agile product delivery?
According to Scaled Agile, agile product delivery is a “customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users”.
Agile product delivery forms a core part of agile project delivery. Each project is delivering a particular product and this is concerned about delivering innovative products and services with the right solutions at the right time.
The mechanics within each product delivery add up to determine the overall project outcome. Therefore, the design of agile product delivery practices is absolutely crucial in achieving overall project goals. Let’s now examine some of these practices in detail.
Customer centricity vs project centricity
In agile methodology the end customer is the number one focus. In various organisations ‘customer’ may be used for various internal stakeholder groups. Yes, often projects may be delivering solutions that are only benefiting internal employee groups. However, the end goal for agile is focused on the end external customer.
This means, whatever solutions or benefits that the project is bringing to the internal stakeholder group, ideally these would support the organisation’s work in benefiting the end customer. In all aspects of prioritisation and discussions of solution design, the focus must always be on the end customer.
The role of the change manager in customer-centricity is to plan out and execute on the change process according to what supports the end customer. If the change has a direct impact on the customer this means engaging the customer (as needed through marketing groups). And if the impact is more on internal stakeholders, thinking still needs to be applied to facilitate the engagement, readiness, and adoption of the change so as to benefit the end customer.
Even when you’re working on internal stakeholders, being customer-centric means:
Putting yourself into the customers’ shoes – Using customer insights and data to inform insights
Focusing on the whole product vs individual features – Taking a holistic view of what is in the interest of customers, the design of the overall change should take into account how customers interact with the overall service or product
Designing change to the customer lifetime value – Most organisations would have a mapping of the value delivered to the customer across different phases across time.
Develop on cadence in agile change management
Agile teams have ongoing, structured routines that help them develop solutions on a regular basis. Within each iteration (a standard, fixed timebox where the team delivers incremental value) the team aims to deliver according to plan.
The Change Manager needs to understand the broader plan and milestones of key outcomes delivered by the project, as well as when each iteration will occur. From this project plan, a clear change plan detailing the overall approach in engaging stakeholders based on what will be delivered and the frequency and nature of communication should be formed.
Careful attention needs to be placed on setting the expectation with stakeholders on the readiness of developed solutions. A lot of stakeholders may not be comfortable with how fast solutions may be iterated and that the solution outcome may not be known until, often, closer to the release date. Addressing the stakeholder expectations of release cadence is critical to ensure that there is no misalignment.
Program Increments (PIs) informed the larger timebox of what will be delivered, whilst each iteration delivers a smaller set of solutions. From a stakeholder engagement perspective, there needs to be a balance of painting a clear overall story of what will be delivered within the overall PI, balanced by particular details contained within each iteration.
Working in program increments
To add value as a change manager across a program increment it is critical that you examine the overall program as a whole system. Across the work of each agile team and each iteration, the overall program solution starts to take shape. Your job is to interpret what this means to stakeholders and decipher this into engagement and readiness activities.
Sequencing and planning
The schedule of agile releases is mainly determined based on agile team resourcing and delivery deadlines.
Throughout the iterations, how do the release timings impact stakeholders against their existing business-as-usual demands as well as potential releases from other projects? This is a key contribution of the Change Manager in ensuring that change impact release plans are optimised from the perspective of the receiving business. How frequently should communication updates be undertaken for various stakeholder groups given the pace of the releases? Again, the design of this forms a critical part of the overall change plan.
Change delivery also forms a central part of agile team delivery. Change deliverables are often dependent on other agile team members. For example, to deliver change impact assessment you need the finalised solution to be defined by the Business Analyst. In order to deliver the right level of communication briefing to business stakeholders, you need to set the expectation of the timing and minimum information required.
Overall vision and narrative
Is there a clear overall vision and narrative from which individual release communications can build on top of? It’s critical to paint a clear picture of what the end state looks like without the nuances of the mechanics of the solution (as these will not be known at the beginning of the program).
Release on demand
Release on demand is a practice and a process whereby new functionality is deployed as needed based on stakeholder needs. Depending on the change impact of the feature the change manager needs to be ready to send communications and updates as needed, sometimes within a short notice period.
Note that not all releases necessarily require communications for users. And depending on the type of change being released different formats of communication may be leveraged. For example, system changes may benefit from within-app notifications versus emails or other forms of update.
Communications and engagement may also be bundled as necessary to provide a packet of updates to stakeholder groups versus constant and continuous updates. The change manager needs to examine the nature of change impacts and stakeholder needs to determine the right tactic to be used.
Change impact sizing and design is a critical role taken by the change manager. From change impact assessment, the change manager needs to consider the impact of the overall size of the change impact from a business stakeholder perspective. Where possible, a packet of change may need to be de-scoped to be broken into smaller pieces of change if this is going to be easier for adoption in consultation with stakeholders. On the other hand, many changes may also be bundled together into a larger change release, again based on optimal stakeholder adoption considerations. This form a critical part of lean flow design.
Bugs in agile change management
The change manager has a role to play in setting expectations with stakeholders that with agile system releases that go fast and constant, that there should be an expectation that bugs are probably unavoidable. Ensure that users are clear in terms of how to highlight bugs and how they will be kept in the loop as each bug is addressed.
On the other hand, bugs may be so disruptive that an effective roll-back approach must be in place in case the change did not land well. Effective communication content and processes need to be in place to manage this risk. This is a critical part of ongoing agile change management.
With frequent releases, care needs to be given to how the change will be adopted and embedded within the impacted business as a part of business-as-usual. For smaller changes, this may not be critical but for larger change impacts the change manager needs to weave each change into a coherent, overall change approach that includes post-release adoption strategies. This includes embedding roles and responsibilities, tracking, and reporting mechanisms.
Automation in agile change management
A part of agile is about delivering fast as frequently as possible. To support this automation of any part of the development process is encouraged where possible. For the change manager, various digital tools should be leveraged to support the continuous deployment. This includes scheduled digital communication, tracking of audience responses, knowledge article views, and digital versions of the single view of change.
Measurement in agile change management
Measurement is a critical part of agile change management. Without the right metrics to indicate how the change is progressing it is difficult to know if the trajectory is heading in the right direction towards the end state. A clear set of measurements needs to be in place to measure constant, and continuous change releases.
Research on aversion to loss can explain why people don’t want to change. I spoke with senior fellow, anthropologist and ex-Inteller Tony Salvador.
It sounds completely illogical but true ….
People would be more concerned about losing something than gaining something. They would rather not lose $2 than to gain $5 for example.
This plays out in various facets of how people make decisions about choices … including in a change context.
This is just one of the many things I spoke with Tony Salvador about.
Lots of golden nuggets of wisdom takeaways for change practitioners from the man who spent 30+ years working for Intel researching about people behaviour and how they operate in social and technological environments.