Where waterfall development is all about setting out from A with your eyes firmly on Z, Agile development focuses your attention closer, first on B, then C, and so on until you have all your desired features. (Often, you’ll realise that Q to Z are unnecessary, or your requirements actually stretch far beyond Z; Agile allows for that flexibility.)
Agile change management follows the same principles; it’s an iterative approach that reduces risk and allows for more manageable progress through evolution, whether that’s within your development team or on a wider scale. Here are three ways to make Agile change management work in your organisation.
Engagement on every level
It’s a simple and universal truth: if you give people too many extra tasks to do on top of their everyday work, they’ll resent it, and they won’t want to do it. And that’s often how projects and organisational changes fail – without enthusiasm and engagement, things just don’t happen.
A modular approach to managing change is far more effective than expecting everyone to get on board with a major adjustment from day one.
Truly Agile organisations operate without the traditional hierarchy scaffolding that other businesses have, but that’s difficult to replicate without a long road of incremental changes. So start small, and introduce your plans well in advance, communicating the value clearly to help people get on board. Changes shouldn’t be a surprise – and they shouldn’t be dictated, either.
The best changes are informed by everyone’s opinions and experiences, especially when you’re making changes to the everyday processes your people follow. People are far more receptive to change when they have ownership of it, with responsibility for meeting targets.
The right KPIs
Focusing on the wrong KPIs will be the downfall of any type of project. But the wrong KPIs aren’t always obvious, which makes it easy to trick yourself into thinking a project is progressing well when there’s trouble brewing under the surface.
I like using the fruit metaphor: the wrong KPIs are – bear with me here – watermelons. Vivid green all over and, if you’d never seen one before, you’d be forgiven for thinking they were green all the way through. But they’re not. Underneath, they’re bright red and full of black pips.
‘Watermelon’ KPIs are measures that seem to signify success, but if you cut through the skin you find that they’re hiding a whole host of problems. These tend to be big, bloated KPIs that look good on a PowerPoint slide, but lack the nuance you need to monitor a project’s progress. Say you’re keeping track of error reports, and you’re only getting one a week – that looks good, right? But if that weekly error is consistently coming from the same feature, it’s still an issue.
I prefer ‘kiwi’ KPIs (or perhaps ‘white grape’ KPIs, if you want to get more granular). They’re smaller, easier to monitor and, crucially, green all the way through. Just like developing in small chunks, you should measure success using more manageable KPIs – and you’ll get a more accurate picture.
Developers that sit outside the hierarchy
Agile works best when the whole organisation is on board. But it can be difficult to scale. In large multinational companies, it’s almost impossible to dismantle the processes and hierarchies that have built up over the years – and trying to do so risks enormous disruption.
The aim of Agile isn’t to be disruptive; at least not in that sense. It’s designed to be fast, iterative, and outcome-focused, but that’s all aimed at getting people the tools and systems they need without the major upheaval of big-bang changes that often arrive at the end of a waterfall project.
If you’re looking for an Agile approach to software, working with developers that sit outside of your organisation’s hierarchy means you get all the benefits of Agile without having to rethink your entire structure. That means we can stand up new tools and software quickly, helping you see value sooner. And if the Agile approach appeals to leaders on a broader scale, it’s the perfect halfway house for wider organisational change.