“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 CM. Because many CM 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 CM 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 CM to key success factors and obstacles[1].

1. How do iterative methods impact CM?

The answer is pretty straightforward: CM must itself become iterative, aligned with sprints and releases. It is only logical that CM plans should be turned into, say, “provisional by design” documents. The hardest part for CM 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 –, CM 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 CM 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, CM 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, CM 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 CM 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 CM, 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 CM. 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 CM “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 CM 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 CM practitioners are left behind.

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