Why Change Managers Are Failing in Agile Environments – Part 1

by | Jul 23, 2020

Part 1 of 3: Who needs Change Management when you can be Agile?

We all know why large projects fail. It usually isn’t because the teams aren’t talented enough, or because there isn’t enough money dedicated to the project, or even because the wrong solution is chosen to begin with (although those things do occasionally happen). No, most large projects fail because of poor interactions between people: communication is lacking, expectations aren’t set, adoption doesn’t occur, and decision-making processes aren’t clear. Thankfully, most companies understand this and invest in hiring change managers like me to work alongside project managers, and together, ensure all aspects of a project are managed appropriately throughout the project’s life. Some smart people out there even developed change methodologies that beautifully align to the standard aspects of a project and have long served change managers well. But about two decades ago, Agile, and other rapid release methodologies that don’t have a project manager, a project plan, or detailed requirements, started gaining momentum. Without these standard project management aspects, this new approach began to disrupt the change manager’s role and their ability to be effective, which left us change managers wondering where we fit in.

Generally, rapid release methodologies do not call out the need to incorporate many change support activities, let alone identify change management as a specific role that is needed. Is that because these methodologies solve communication issues, unify disconnected expectations, or resolve the need for user adoption? Does the organization no longer need change support if they go Agile? Heck no! This has change management written all over it!

An organization in an Agile environment depends on its employees’ ability and willingness to adopt constant change as part of their jobs. But change is stressful, and constant change is constantly stressful. And when employees are worried about their ability to keep up in a constantly changing world, resentment, resistance, and a lack of adoption can slowly set in if proper change support is not established early on.

Unfortunately, there are very few practical resources that break down the different change elements and support needed in rapid release environments. It’s not as simple as just using “mini” versions of standard change plans (as some people have suggested) because that still assumes traditional project management roles and deliverables are in play. On top of that, pushing a standard change framework onto an organization that encourages teams to work quickly and autonomously can even cause increased resistance within those project teams.

To complement the fluid nature of a rapid release environment, and not add friction to progress, a change manager needs to realign their approach to the overall project and right-size their change activities to fit each release. Doing this effectively will depend on two factors: 1) How much of an impact will users have to manage? 2) How mature is the organization in their ability to execute rapid releases? By simultaneously managing change at the release level, as well as right-sizing the efforts based on the organization’s maturity, a Change Manager can dramatically affect the likelihood of user adoption and overall project success.

In the next two parts of this series, we will do a deep dive into how to approach these two areas differently:

1.     Supporting change, one release at a time: As with any initiative, the impact and scope of the change being undertaken drives the amount of change support that end users will need. From a general back end change to starting a user in a new system, the scope of change can vary greatly in rapid release environments. Not every change will need a communication plan, or warrant using complex survey models, so it’s important that a change plan is right-sized to the scope of each release.

2.     Supporting the shift to rapid release: To get the most value out of a rapid release methodology, the development team must implement a Minimally Viable Product (MVP) and iterate on it based on learnings gained along the way. In life, however, people don’t generally receive minimally viable products with constant updates – they buy fully developed products and update it whenever it stops working. This means expectations have to be reset across all levels of the company, so that employees are more likely to adopt the changes right at the beginning. This allows the development teams time to learn from previous releases and create a product to its full potential.

READ MORE

The Magic of Mortals

The Magic of Mortals

Daily we wake up to new developments in automation, Artificial Intelligence (AI), and Machine Learning (ML). Across sectors and industries, automated solutions prove highly successful in surpassing the capacity of the human brain for certain tasks, improving...

read more
Leveling Up: How to Hone Your Skills at Home

Leveling Up: How to Hone Your Skills at Home

Leaders have been trying to crack the code on talent development for years. Recent studies have shown, however, that strength-focused leadership [read: intentionally elevating the qualities that already come naturally to us] is the clear winner for developing talent...

read more
Fake Case Study: Jack of all trades vs. Master of One

Fake Case Study: Jack of all trades vs. Master of One

  Listen to any earnings call or executive presentation and you will likely hear the terms “top line” and “bottom line.” These are words used to describe a business’s performance. According to Investopedia, the words are defined as follows: Top line refers to the...

read more
Your Personality Is Showing

Your Personality Is Showing

There I was, minding my own business one evening, digging into my organization's SEO performance (as one does), when I came across something interesting. Search terms related to "MBTI" — or the Myers-Briggs Type Indicator, developed by Katherine Cook Briggs and Isabel...

read more
Lessons From a Change Manager Who Hates Change

Lessons From a Change Manager Who Hates Change

Hello. My name is Monique, and I’m a change manager who hates change.   After years of receiving “consulting therapy” from various mentors, I am now able to say these words out loud and proudly. But for a long time, it felt more like an admission of guilt. I mean, who...

read more
Creativity as a Cure

Creativity as a Cure

The topic of creative solutioning has been front and center these days as we talk more and more about organizational adaptability in the face of dynamic and uncertain times. For example, I recently read about a project that got me thinking about specific priorities...

read more
Thought Ensemble, a Pariveda Company — Why Now?

Thought Ensemble, a Pariveda Company — Why Now?

Big news over here as we close out the year - we have been acquired by Pariveda, a 750-person consulting firm in 12 markets across North America! We are now “Thought Ensemble, a Pariveda Company” and I’ll be serving as the Managing Vice President continuing to lead...

read more
Thought Ensemble Joins Pariveda Solutions!

Thought Ensemble Joins Pariveda Solutions!

Dallas, December 9, 2021 /PRNewswire/ -- Pariveda, a leader specializing in solving complex technology and business problems, announces the acquisition of Thought Ensemble. With the addition of Thought Ensemble, Pariveda now provides holistic business strategy,...

read more
Thoughts on Colorado’s Equal Pay for Equal Work Act

Thoughts on Colorado’s Equal Pay for Equal Work Act

It was about a year ago that we first started hearing about Colorado’s Equal Pay for Equal Work Act (SB19-085) and I knew it was going to be national news. We’d just gotten past the “Rocky Mountain High” jokes, and our lovely state was trying to break new ground...

read more