Change Management and Agile: Best Friends or Mortal Enemies?
Traditional project management methods and classic notions of change management used to share a common strategy for controlling risk through the application of structured processes, robust documentation and rigorous checkpoints. As many organizations have moved on from waterfall project management and embraced agile delivery methods in a desire to accelerate value realization, many are wondering what this means for change management?
Is change management still needed in modern organizations and if so, what is the relationship between change management and the Agile methods that companies love so well? Can they become best friends, or are they destined to become mortal enemies? The answer to this question depends on a couple of things. First is an understanding of why companies have pursued Agile as a replacement to traditional project management methods and second is a re-evaluation of what change management is really about.
At its core, both Agile and change management are project management methodologies. To really find the difference let’s drill down into the specifics.
Agile: Born out of a revolution
The Agile revolution (and it was a revolt) was the response to the slow pace at which things (software in particular) were getting delivered within organizations. Projects were becoming too big, processes too burdensome and timelines too long – changes and risks were being queued and compounded to a point where issues at the time of implementation were almost a certainty. The organizational response to these problems was adding more process rigor.
It was a cyclical problem that was getting progressively worse until a group of thought leaders got together and declared “Enough!” The Agile Manifesto was born and with it the start of a grass-roots movement that would change the culture around projects forever. The cycle of risk and process rigor feeding off each other was reversed. With Agile methods, when issues were encountered, they were addressed through progressive simplification of processes – reducing risk by avoiding unnecessary queuing and thus lowering the impact should an issue occurred. Companies realized that through simpler, Agile approaches to project/work management, they could acquire value faster and with a greater likelihood of success. Agile became their “lean and mean value delivery machine”.
Change Management: neglected and misunderstood
So what about change management? Most people misunderstand what change management is all about. Some think it is either some sort of metered gate to control the flow of changes or some sort of quality control process to prevent ambitious delivery teams from messing up production environments. In reality, change management is just another type of project management. Change management is all about managing the implementation and adoption of available features into the organizational environment – it’s the same project management processes in a different context. Unfortunately, most change management processes are still stuck in the old ways of thinking.
The reason companies are seeing conflicts between agile delivery methods and change management is that they are failing to realize that change management must become Agile too. Delivery and implementation activities need to have complementary cadences. It isn’t necessary for them to be exactly the same (with the proliferation of cloud services that isn’t really practical). They can’t be allowed to be in constant conflict with each other either. The benefits of agile delivery can only be realized through a complementary implementation cadence that enables the treasured ‘feedback loop’. Perhaps it is time for change management to go through its own agile revolution?
Change management and Agile – best friends or mortal enemies? That all depends on you – bringing these two processes into alignment will reduce risk, enable you to realize value sooner and increase the quality of the feedback loops to your development team. Leaving them out of alignment will negate the value that Agile seeks to achieve and create persistent conflict amongst your IT staff. What path is your company on?