There are easily 40 change methods out there. If there was a best practice, shouldn’t there just be one? Throughout the last few decades where change managers roamed the world, haven’t we figured out the one process that works?

I’ve said this before, but I’ll say it again. We *know* we need good communication, a reason why, strong leadership, a strategy, a plan, and some level of acceptance by the people impacted by the change, but in all my readings, I’ve rarely come across writings that say we need to create the best, standardized process.

I’ve been speaking at Agile and Change Management conferences about the merging of these communities for the last few years and it seems like people are ready to pay attention now that Agile has gone mainstream, more or less.  The Agile Manifesto was created in 2001, and the ideas behind most change methods have existed for 4 times as long. While the Agile community is starting to pull process models and ideas from change management, the change management community is attempting to learn how to apply Agile practices to change.

The difference between the two is, the Agile Community is largely principles-based, while the change management community is largely structure, and process-based. When the Agile Community discovers a new-to-them idea, they mostly share it openly. When the Change Management community discovers a new-to-them-idea, they mostly create a closed think-tank, or private committee to create a process out of it.

Obviously that’s a sweeping generalization, but the pattern is there.

The first value in the Agile Manifesto is: Individuals and Interactions over Processes and Tools

That means, we value the statement on the right, but we value the statement on the left more. People who value process, and crave order and structure read that statement and immediately leap to the conclusion that Agile means no process which is incorrect. That’s typically because the ‘Agile’ they’re seeing in their organizations is the wild west, not the disciplined set of Agile practices that spawned from a principles-based manifesto.

Again, we value some process and tools, we simply value interaction more. Here’s an example. We don’t need a process model for a business change manager to attend an Agile team’s planning session or bi-weekly (or weekly) demo. ASK THEM TO ATTEND. THEY’LL PROBABLY SAY YES! (yes, I’m yelling!) I’ve seen large organizations spend millions of dollars, literally millions of dollars creating a diagram with a few loops that over-complicate a problem that could be solved with a conversation.

If a project has a substantial business change impact, the change manager becomes a core team member. That’s it. What prevents that? The org chart. Who should people in an Agile team report to? How should the change manager be managed and measured? It’s all of these organizational obstacles that get in the way. If we truly want to embrace Agile in CM, it’s a matter of unlearning decades of silod thinking. That same thinking is rampant in Agile as well. It’s just as difficult to integrating development, testing, ops and business into an Agile team as it is to integrate change management.

Applying Agile methods in change management is one small step toward a more effective way of working. There are various Agile methods that approach change as revolutionary, or evolutionary. Either rip the bandaid off and disrupt the joint, or start where you’re at and evolve over time. The hard part is knowing when to choose which approach.

I’ll be speaking at ACMP’s upcoming conference in Toronto that will demystify Agile, and give you a set of tangible practices you can try using right away. The goal is to create the minimal amount of process that works in your context. THAT is what Agile is all about.

[button link=”http://www.acmpconference.com/canada/Program”] Program Details[/button]