But, let’s not be under any illusion; Agile Change Management is not a real thing. Even more importantly trying to shoehorn Change Management and Agile Development into the same pigeonhole is never going to be useful to anyone.
Change Management is about how we facilitate change activities within an organisation to ensure that we are trying to do the right things, for the right reasons, and with the best interests of the right people as the paramount consideration in our change initiative.
Agile Development, on the other hand, is a mechanism for building software in such a way that it provides a continuous value stream to the people who need to use the software (as well as making life better for the people who develop that software).
With that important distinction in place, we’re now in a better place to understand how we can use concepts from one discipline to get better outcomes somewhere else. So, what can we learn from Agile Development that we can use when we are looking at Organisational Change? Can we cross-pollinate ideas from one discipline of building software to another of managing change?
Since there are so many people who think that ‘agile’ is all about whiteboards and stand-up meetings, let’s start with them and get them out of the way. To be honest, I’d suggest these are no-brainers. Much of our work in Change Management is about communication and these two tools are all about improving communication within an agile team. A simple whiteboard is a great way to visualise what’s going on in a change initiative and helps us to understand flow through the system. A whiteboard is great for the change team or even the leadership team to see at a glance what’s going on and a useful driver for those sometimes difficult conversations. It beats a project schedule hands down and can be understood by most people without a detailed explanation.
In the same vein, the daily (stand-up) meeting is a useful addition to the communication tools at the change team’s disposal, and again could be extended to the leadership team, depending on your organisational context. There’s nothing magical about a daily (stand-up) meeting. It’s what all meetings should be; focused, short, inclusive, and action/outcome oriented. (Daily meetings don’t have to be stand-ups, but to keep them short and dynamic it helps.)
In my previous post, I hinted that only three elements of the Agile Manifesto were appropriate to Change Management. These were:
- Simplicity
- Support, trust and motivate people involved
- Regular reflections on how to become more effective
The daily meetings and the whiteboards are great examples of some ways to realise these requirements. Regular retrospectives (post milestone reviews) are an additional tool that can be used to further support the third of these. But clearly, there’s a lot more to agile. When we go back to the Agile Manifesto, there are (arguably) three principles which underpin the whole ethos behind Agile Development.
- Customer Satisfaction through early and continuous software delivery
- Accommodate changing requirements throughout the development process
- Frequent delivery of working software
There is a really good reason why these are so important in Agile Development. Often, when we create a product which is highly reliant on software, we have very little idea of what the end product should look like. Even if we do, we often don’t know whether it is possible to achieve. When we first started building large software applications we attempted to get around this problem by analysing and defining everything up front, writing huge specification documents, followed by myriads of design documents and finally cutting the code to bring it all together. The problem with this approach is that when you get to the point that you’re writing the code and the customer (or product owner) wants something changing, it becomes very difficult and very expensive to build that change into the system.
Agile Development attempts to circumvent the problem by having a vision of the end product, but only developing small chunks of it at a time. Chunks that can actually be of use and valuable to the end user without having to wait for the complete product. This reduces the risk of having to rebuild vast amounts of the system when requirements change, or when implementation problems arise, and hence reduces the cost of the final product. At the same time, it gets over the inherently human problem of not knowing what we don’t know because it enables us to learn more about what we are building as we build it.
This is where things get tricky when we try and adapt these principles into organisational change (unless of course, our organisational change is all about a large software implementation like an ERP - Enterprise Resource Planning -system). It becomes clear why when we paraphrase the principles in terms of change
- Customer Satisfaction through early and continuous change
- Accommodate changing requirements throughout the change
- Frequent delivery of change
Often, organisational change is not something we can easily do in chunks. Rolling out a new organisational structure a bit at a time over several months brings about chaos - I’ve seen it happen on more than one occasion. The endpoint of an organisational change is usually very well understood, and indeed, changing the requirements of a change initiative during the initiative will invariably cause many problems, and may lead to many more issues in the future when trust is lost in the ability of the leadership to deliver change. Finally, when an organisation become a conveyor belt of change with no respite, organisation change fatigue sets in; the people within the business cannot take on more change and uncertainty and they have no more appetite for it. When this happens, their only option is to push back against the next set of changes, regardless of how important they are.
While some changes do require a big-bang approach, it is still possible to structure a strategic change programme into a number of tactical initiatives using this agile approach. And instead of defining a huge change programme upfront, designing all the different pieces before finally implementing them, we can use the agile approach to deliver vital pieces of the overall puzzle and constantly adjusting what gets done next by regularly revisiting the requirements and the urgency of their implementation. It’s also possible to build in slack into the frequency of change experienced by different groups in the organisation by changing the target groups on a regular basis. And of course, it is critical to constantly monitor feedback and engage with the affected stakeholders throughout the programme. And when you take an approach like this, it’s even more important to keep your communications flowing, being prepared to explain why you’re taking the decisions to prioritise certain tactical changes over others, and above all, keep things transparent.
But you know what…Let’s not get ahead of ourselves and start calling this “Agile Change Management”. It isn’t. Because ‘Agile Change Management’ still isn’t a thing!
Posts
