Reach out to the founders, Dr Jen Frahm and Lena Ross. They're experienced at designing and building leadership capability during change and navigating agile environments.
Agile Change Management
My fellow change managers we need to talk…
A few years ago fellow change manager Nick Martin and I presented at Agile Australia on Translating OCM for the Agile community. The talk came about as last year when I attended the conference I was surprised at how many of the Agile community did not understand OCM or what a change manager does.
Having just wrapped a great experience of Agile OCM with a Workday implementation, Nick and I thought we had some value to share in a bit of a show and tell of what we did and some broader insights on Agile OCM.
It went really well – but what really surprised me afterwards was I had about a dozen Agile coaches approach me and say things along the line of “yeah, what you did was great and you get it, but we don’t get to work with change managers like you. We hate working with change managers”. I recently caught up with Agile Coaches and the SAME complaints came up!
There were three primary beefs:
- Change managers hate change and are control freaks
- They spend all their time protecting people from agile initiatives
- They just want us to tick boxes on spreadsheets.
Let’s unpack these a bit…
You hate change
I’ve long asserted that change managers often are change managers because they don’t like change and they like to be on the front foot of it rather than the receiving end of it. I know I am, and I see it in a lot of my peers. I’ve also seen that organisational change managers are often appalling bad at future proofing – keeping up with new trends, practices etc and exploring.
Moving to an agile way of working means thinking about control in a different way – one where you can “control” the change process through different means – data, insights, feedback loops, co-creation. The use of build-measure-learn feedback loops and #failfast actually give you much greater control over a change implementation.
It also suggests that a great recruitment question for agile change managers is tell us what the most recent technology is you have embraced and why. If they are stuck for an answer, they are perhaps not well suited for an agile implementation.
As a side note, OCMers don’t take it too personally. I met many Agilists who were surprisingly rigid and close minded (this is the ONLY way to do agile).
2. The protector of the people
We know inherently that our role is to help people through the change process. But I have seen the phenomena where change managers embody that role in a highly protective way, rather than think about how to do you encourage people to adopt, explore, try the changes. It’s a subtle shift, and one that is worth exploring with agile coaches on your initiative. Often in our desire to appease our people (provide more training, more WIIFM, more support) we are actually encouraging learned helplessness in the workforce. Change can often and should often incur discomfort. Protecting people from that discomfort is not necessarily the way to go. You don’t create change!
3. Tick the box.
Great agile is built on the foundations of great OCM (communication, collaboration, co-creation). There shouldn’t be that many disconnects. But along the way, the rise of accreditation paths, commercial change management processes and enterprise Change Management Offices, the change management process has become very ‘tick the box”, produce this artefact. This of course is the antithesis of agile OCM. It sounds like there is a lot of overlaying of waterfall change management processes in to agile initiatives (just do it faster!). This of course is not necessarily the fault of the change manager – it’s indicative of a lack of commitment to agile at an organisational level and a redesigning of the PMO or CMO towards agile practice.
A note on Role Conflict
One of the points that the agile coaches I spoke to did agree with is the potential for role conflict – OCMers often have the same skill set and qualities as Agile coaches and unless there is an explicit conversation about roles and responsibilities there is potential for role conflict. This is because a good organisational change manager has a very broad tool kit and is very flexible. They are the protean project team member – facilitator one day, driver and motivator another, problem solver on the next and protector of the user or person who is on the receiving end of the change. Which is AWESOME if you need these capabilities bolstered and amplified. But the scrum master or agile coach is not aware of this, it can lead to role conflict. It’s worth a conversation at the outset as they often share the same characteristics
So what to do next?
Start educating yourself on Agile, there’s some breadcrumbs in the links below this post. Have a read of the Lean Start Up by Eric Ries. Search for blog posts written by agile folk. Make time to have a coffee with your company’s agilists and learn more about their world. Attend a meetup within the agile community. Attend conferences about Agile. Ask about one or two day course in Agile. Future proof.
If you are operating in an enterprise CMO, have a chat with the powers that be about the direction with regards to Enterprise Agility. There’s nothing wrong with structured processes provided they are fit for purpose and not a barrier to delivery. Similarly, change accreditation is not necessarily a bad thing, but it does not make you a change manager. It is your personal learning starting point, not end destination.
Have a quick look in the mirror – are you totally open to new ideas yourself ; -)
When frustrated with a change practitioner, take a moment to think about who this persons reporting and reward structure is. It may be they are hamstrung by the funding model of project delivery?
Can you offer to take a change practitioner through your boards and explain the purpose?
Patience and persistence – you have been doing this for longer than the OCM folk (in this very specific jargon heavy world), not everybody learns new languages and customs at speed.
But to both of the Agile and OCM communities – what are you doing to understand each other’s world better?