“How to” integrate CM and Agile: what you need to know before starting.

In our first instalment, we reviewed the set of values and principles common to both Agile and Change Management. Because many Change Management assumptions and standards find an echo or are mirrored in Agile, both disciplines can work in synergy to deliver extra value. But how exactly should you integrate Change Management and iterative project development? And how different is the approach to managing the people side of change in an Agile environment with respect to one running on Waterfall methods? Here is everything you need to know before starting, from the impact of Agile on Change Management to key success factors and obstacles[1].

1. How do iterative methods impact Change Management?

The answer is pretty straightforward: Change Management must itself become iterative, aligned with sprints and releases. It is only logical that Change Management plans should be turned into, say, “provisional by design” documents. The hardest part for Change Management practitioners is certainly to let go of any integrated plan intended to constitute a single point of reference throughout the project. Think “just in time”.

Also, be prepared to deliver more work upfront. Whereas the technical side of change can benefit from less planning, or from being planned very loosely – a standard argument among Agile advocates –, Change Management requires more planning upstream. Being prepared to respond effectively to any demand on a very short notice takes some serious preparatory work. At stake is the ability for the Change Management team to adjust communications and training plans when needed and to offer immediate support whenever a particular release impacts people’s routines in a significant way.

All in all, Change Management planning, activities and analysis must be performed in less time and at a faster pace. If we consider the case of releases scheduled every 2 to 4 weeks, Change Management practitioners must be ready to sync and adapt in that time frame.

2. What are the key success factors?

Based on what we have just said, early involvement of the Change Management manager is essential. Adoption and usage are key metrics to bring up to the table sooner rather than later as Agile means operating within extremely short time frames. 

Of course, communication efforts must be coherent and derive from adjusted plans. Furthermore, just as sponsorship consistently ranks as the number one success factor for Change Management, so is the unwavering commitment of leaders in an Agile environment. And last but not least, early “victories” inherent to the sprints scheme must be told and shared, for they create momentum and have a measurable impact on the organisational process.

3. What are the main obstacles?

Because they focus on the technical side of Agile development, Agile developers sometimes show a lack of understanding or appreciation for Change Management. Often seen as a simple add-on and an extra burden, developers tend to put it aside. Simply put, they don’t see where exactly Change Management “fits”. Equally challenging is the issue of organisational resistance to Agile. Switching from Waterfall methods to Agile demands a shift in mindset, in addition to dealing with the change/project per se. The journey is certainly no easy ride and resistance may arise because people do not understand the benefits of the approach and/or cannot come to terms with the new significance and manifestation of change in an Agile framework. The fact remains that lots of resources are often allocated to Agile experts, but the transition to Agile itself or better said, the sum of individual transitions, is often incomplete and patchy. Resistance can become highly problematic when it spreads among middle managers. In charge of cascading the change, managers are very much looked up to. As a result, resistance spills over onto frontline employees and solidifies.

The high volume of incremental change also makes it harder for Change Management practitioners to generate buy-in among impacted people and to respond to the inevitable “what’s in it for each of them” question. Bundling small changes together is often seen as a solution, but one that Agile developers are unlikely to validate as immediate releases are considered the very essence of Agile. Overall, the increased pace sometimes creates a two-tier system where Agile developers rush through - delivering on technical requirements -, and Change Management practitioners are left behind.

If you are interested in learning how to adjust the Change Management approach in practice and set yourself up for success, do not miss our next post!