Managing Change in Agile Delivery Programmes

By the time the Agile manifesto was published early 2001, various teams were already using Agile methodologies. In the past decade the adoption of Agile has catapulted to a whopping 71% of organisations using Agile approaches in 2022.  Especially since larger digital transformations with huge impact on organisations have been managed in Agile ways, change practitioners too are in on the Agile plot.  However, even if change professionals fully comprehend Agile methodologies such as Scrum, Kanban, Devops and Scaled Agile, change practices are not always fully adapted to Agile yet, resulting in suboptimal outcomes.

How can Agile and Change complement each other optimally?

Ever since being involved, as a change manager, with Agile lead programmes for the first time in 2013, I have researched, tried, experimented with and found different answers to questions like “How does change work within Agile Teams?”, “What is the Definition of Done for change?”, “Can we derive change impact from user stories?” and “How is change best organised in an Agile programme?” In this article I share my findings; my quest for seamless integration of Change- and Agile practices is ever continuing.

In this article I review the position of change management practitioners within an programme that is already lead in an agile way.

The good news

In theory, Agile should be every change managers´ dream come true, as by design, Agile ways of working are meant to make adoption of changes easier. Development teams incrementally release small changes that each add business value after first being reviewed by users. So, if we look at that through the lens of the Change Equation theory ( C =D x V x F > R) by Dannemiller, based on Gleicher, things are looking great. Agile development is prioritized based upon added business value (e.g. it resolves a problem or it helps reach business vision and strategy), and initiatives are placed on the backlog because they fit with the clear and compelling vision set forth by leaders. Theoretically that means that any change that is released will tick the box for (D) Dissatisfaction with the status quo and (V) Vision. As changes towards larger, more audacious goals are segmented into smaller, tangible improvements, we can also tick the box for (F) First steps, making the scales tip deeper than the Resistance to Change. So it seems change management is supported fully by the way Agile teams deliver.

All of that is a great start and it does partly answer the question: “How does change work within Agile programmes?”, but not fully. Some say change, being a crucial and enabling discipline, should be part of the agile delivery teams, so that they can manage change in real-time. Although that sounds perfectly logical, I´ve experienced having to work around the following issues.

The issue with managing change from within Agile teams

If a change programme is supported by one to three Agile teams, this wouldn´t cause any logistic concerns. However, large impactful programmes tend to work with many teams (10+ up to 500). Although it does make sense to be very connected to all teams, it is logistically difficult to really become an agile team member and tune in to the details of every single team for a team of change professionals. Also, when making change-work part of a teams´ backlog, a DoD (definition of done) needs to be agreed for it on the basis of which a product owner can accept it as “work done”. Under such constraints, change managers will be tempted to reduce change interventions to “training” and “communication”, which one might be able to fit into a sprint to make that tick in the box.

The solution: View change as programme encompassing and make sure it started well before the product owners explained their visions to the Agile teams and the prioritized user stories have been placed on the backlogs, and it doesn´t finish with the release of each change. Do agree on change epics, stories and a DoD on programme level, whilst also including change items in each teams´ Definition of Done.

Instead of inserting change managers into every Agile team, enable a change agent network consisting of business representatives, to be part of the Agile teams. The change team can in this way make sure all the changes are kept in the loop of the detailed change plan, whilst never losing sight of the overall change journey and keeping all stakeholder groups engaged. 

The issue with using user stories to identify change impact.

Let us use an example of this (simplified) user story that one Agile team may deliver in a sprint: “As a sales operator I need to be able to create a customer record, so that I can create sales orders in different sales regions”. The team may release this functionality integrated within a larger application that is being configured. For someone looking at this user story it may seem that the change impact is limited to users having to use a new interface to perform a process they are already used to. The appropriate change intervention might be to inform and train the impacted stakeholders. Someone looking beyond this user story, might find it is connected to various changes delivered by multiple teams which together have an impact on the data structure of 10 sales regions and needs a massive data cleaning exercise performed by business resources that still need to be made available. Some of the additionally proposed change interventions may then be: wider conceptual and detailed communications building a burning platform, consultations with leadership teams, employee representation groups and unions preparing for the extra strain that will temporarily be put on employees. Such interventions need time.

The solution: when identifying change impact, first work from a program goal and use case level to keep sight of the bigger picture; from there zoom in to user story level. The feedback loop to the overall change impact from user story level ascertains that no details will be missed, whilst the high-level impact will inform a change strategy that will be executed earlier on in the programme, so that overall change goals will be accomplished prior to agile team releases.

Key perspectives

Agile ways of working support organisational change. Applying Agile principles to Change management work such as cadence, DoD and being part of Agile synchronisation events, is a great step forward in managing Agile lead transformations. However, managing change should not be limited to Agile teams only. It best operates on different levels; with leadership, product owners, teams and individuals, keeping in synch with both the smaller details and the big picture.