Agile change management?

What do change managers do who work agile principles?

 So I’m at Agile Australia* at the moment. Agile continues to be a growth trend for organisational change practitioners with companies and clients wanting to know what your Agile chops are. Not having done any agile training or certification, I think that I work with Agile principles, but wasn’t too sure.A couple of years ago, I asked Jenny VanDyke to guest blog a post on the difference between change management in waterfall projects and agile projects and her analogy of cooking is worth a read. I certainly resonated with that.After Day 1 of the conference, I’m pretty comfortable that what I do is very aligned with Agile practice, and having worked in Business Improvement teams and companies that use Lean and Kaizen, I have obviously been influenced in this regard.I’ve just sat through the second day keynote – the noted Linda Rising on the Myths and Patterns of Organisational Change. She was very good. The content reflected traditional organisational change practice, not necessarily applied to Agile (or anything different or new in organisational change management). If you are new to projects or change, then definitely do put her on your reading list!But this presentation and the other presentations and conversations from yesterday prompted me to articulate what it is that I do these days that I consider “agile” in my change management practice – and I’d invite Agile practitioners and other change practitioners to chime in in the comments and share your thoughts on what agile change management is.1) It’s International Work Out Loud Week (#WOLWeek) and increasingly I look for opportunities to Work Out Loud. Working out loud requires a commitment to transparency and taking risks. In a previous post I shared a change strategy developed through #wol. Working out loud amplifies the opportunity for collaboration, communication and buy in. 2) I live by the practice of get the artifact / idea to 70% complete and share and ask for others to make it better. At this point there is shared ownership in the artifact (change communications, training material, presentations, plans). Done is better than perfect. 3) I use simple visual management to generate conversations of understanding and influence. This image is of a simple change scorecard I am using at the moment. It’s A3, sits above my desk on my current engagement and see the creases? I pull it down and take it with me to meetings. See the red? Very effective for getting attention – your business unit is red because there is not demonstrable change leadership yet. It gets updated on a monthly basis before the steering committee and is purely subjective. It’s ok if some-one disagrees with me on how I have rated the elements – it creates a conversation on why and I can either learn more and change (see the scribbled red in the top right corner)  or share more information with the stakeholder as to why it is that way and how we can get it to amber or green. Some of these will be red by virtue of not started, but it communicates what has to be done. 4) Communicate, communicate, communicate – ironically (given my background) this is the hardest to do even with the disciplines of “scrums”. We get busy doing. We forget to catch our own teams up with the latest stakeholder issues. But do it we must. 5) I use change roadmaps over change plans – they are easier to change, and more suitable for A3 visual management. A stakeholder will look at a roadmap, they won’t look at a 400 line plan. It is easy for a stakeholder to "insert" themselves in the roadmap, the change plan can shut them out as it is too overwhelming. 6) I play the role of guardian – I guard the language of collaboration (call out non inclusive language), I guard the “personas” in design workshops (they are the people of change) and I guard the value proposition of the project, because this is the What’s In It For Me (WIIFM). It is the change managers role to protect these three attributes and not let the design of the change overlook these attributes. 7) I rely on active feedback loops (or the social architecture of the organisation) and testing (transparency) – we see our change activities as iterations. This is one of the trickiest, because we need to balance the need to include the feedback and the need to know what is the right thing to do from a change management perspective. One person’s co-creation can be another persons “tail wagging dog” or reluctance to embrace the change. Having said that, a true feedback loop permits you to find out why they are reluctant and iterate again consistent with the value proposition.. 8) So much of agile change management is thinking on our feet – we are not wed to processes, frameworks and artifacts, but respectful of all. The time it takes us to write a 40 page change strategy and plan is time we could be having conversations of change with the leadership who need to champion the change. One of the speakers delivered the joke “Methodologies give people with no ideas something to do” . There is some truth in this, yesterday, I got asked many times do I follow [x] methodology and on saying no, was asked how do I know what to do? Agile change management is common sense – you need to be good at triaging, prioritising, nimble, use enough of a process or framework to get momentum, and know when to step away and do something completely different. In the previous post Jenny Vandyke notes that change managers need deep expertise. To a certain extent rigid application of processes is great for people with no expertise in change – in the absence of nothing, thank goodness for the methodology! But to know when to step away, you do need the expertise and learning. So that’s my impression at this stage, still several presentations to go. For those change managers working agile – what are your unique practices that make you an “agile change manager”. And for the bona fide agile practitioners, what makes a good change manager to you? * For the record , it is handsdown one of the best conferences I have been to internationally.  It is a lot like change management conferences though, the awkward clashes of newbies and experienced hands, the definitional dramas of what is Agile, along with argy bargy of which methodology to use. Good fun! Kudos to Slattery IT