Agile is so in Vogue. Over the past few years we’ve seen seismic shifts in product development and project delivery shifting to ‘Agile’ and ‘Lean’. A recent global survey of almost 1,300 IT and business leaders found companies are keenly aware of the importance of agile with 44% of the organisations well into their agile journey.
Out with the old, in with the new
There’s been an emergence of Agile-based professional associations and MeetUp Groups to support growing practitioner communities. We’re even seeing the ‘traditional’ professional bodies releasing their own take on Agile with new practice guides and major changes to established methodologies. But are we throwing the baby out with the bathwater with these “new ways of working”?
As a change practitioner, I have to confess that I chuckle a bit at the fanatical behaviours in some Agile delivery settings. From a change management perspective we’ve always been agile (or should have been)… it wasn’t until project management got its hands on change management in an attempt to integrate ‘effective practice’ into delivery (read: communication and training deliverables) did the conversations about change become more prescriptive and linear. We’re still fighting the stigma of change management being just communication and training. Thank you very much PMBOK, PRINCE2 and MSP, however, that’s a whole other conversation.
What we do know for certain is that the PRINCE2 generation of project delivery isn’t cutting it anymore. Organisations and delivery teams are drowning in documentation and inevitable delays seem to be breeding a burning desire to do things better and faster. Enters Agile, Scrum, SAFE, <insert latest methodology here>.
Agility is more than just software delivery
Personally, I think the influx of conversations around agility is the most sense project management has made in a long time. Agile is putting the consumer of the product back at the heart of product development and delivery rather than ticking a checkbox on a pre-implementation checklist. The problem is that customer-centric design isn’t the answer to organisational agility.
If you ask the IT profession, it invented Agile (in 2001 in fact). Its origin in Extreme Programming is well documented and it’s pretty common to see Agile sprouting from a rogue IT project experimenting with a new way of doing delivery. There’s nothing wrong with this. I’ve been plenty guilty of these guerrilla tactics.
BUT agility has never been about the installation of a new methodology. This little titbit seems to keep being lost in the hype of Kanban boards, Scrum, Retros and building the great wall of post-it notes (for your backlog of course). It’s almost as if we believe we can just ‘add’ agile and it will add up to a magic formula without really considering the bigger recipe.
Just add water
In the same way we saw organisations investing buckets of dollars in training people in PRINCE2 a decade ago, we’re seeing the same patterns playing out with new methodology training that will make organisations agile.
What we’re not seeing is the shifts in how organisations are going to support a fundamentally different ways of thinking, not just the Agile design and delivery of projects. This typically ends up in a spiral of frustration with conventional project governance bogging down Agile teams with traditional ways of doing things.
You can’t just add water and hope that it grows your organisational agility. Technology is doubling the rate of change every eighteen months to two years (depending on who you want to cite). Methodology is never going to be the answer to enabling an organisations’ ability to respond to the rate of change.
Organisations need to consciously enable agility if they want to keep up with the rate of change. I’m not saying that methodology and traditional project and organisational governance is bad. Far from it. It works perfectly fine in certain contexts. Doing away with it all is literally throwing the baby out with the bathwater.
Love it or hate it, methodology gives people a common language to communicate with. Through a common language, we can start to grow a common understanding of what is happening and why we’re doing it. This begins to unlock organisational agility.
Methodology is also only one aspect of the systems and infrastructure that supports organisational agility. Systems create meaning while balancing top down direction with bottom up creativity. While Systems support implementation with the right balance between freedom and constraints to maintain control, they’re still only one component of organisational agility.
Understanding your capabilities gives the ability to make informed, evidence-based decisions on how to grow your organisational agility.
How you think your organisation stacks up?