Q&A: how do I get my waterfall organisation to be more agile?

I was recently asked this question:

How would you recommend working with organisations, who are used to a traditional / waterfall approach, transition towards agile / iterative development?

Read on for my response:

Hi there,

This is a big, big question :-)

I’m planning to talk about digital transformation in much more detail over a series of blog posts based on my work with the Ministry of Justice, GDS and the University of Cambridge. But let me give you a few highlights to get you started.

Lesson #1 – where to start #

The first main lesson I’ve learnt about digital transformation is that you have to start and sustain change in several areas of the organisation at the same time – top to bottom, department to department.

You have get senior management to support it, or at the very least, not to undermine it. You have to demonstrate some benefits of transformation as quickly as possible otherwise you will lose people’s trust and support, and go on demonstrating those benefits as you progress. You need sufficient credit of trust and goodwill so that when something goes pear-shaped (and it will, believe me), people don’t suddenly pounce and declare the ‘experiment’ a failure and use it to justify a return to the old (but more comfortable) ways of working.

You also need to show people in the rest of the organisation that you’re helping them move towards a more empowered and fulfilling way of working. And like anything else, you’ll have people who are early and enthusiastic adopters, a bunch of people who want to wait and see before getting involved, and another group of laggards who will dig their heels in and actively campaign against anything that disrupts their world.

Digital transformation will mean demand for certain skill sets will diminish, just as the gaslamp lighters gradually lost work as electric street lighting was introduced. However, good people with the right attitude, whom you’d want to keep in the organisation, will usually be able to transition into a new role with support and training.

Perhaps most importantly you need to establish whether people understand that transformation is a lengthy process and will mean that things actually have to change. Often I’ve been brought in to help an organisation with transformation, but in practice they really want everything to stay the same – hence the abominations of ‘iterative waterfall’ or ‘wagile’.

Lesson #2 – change the way it thinks #

The second is that you’re not primarily trying to change the way the organisation works, you’re trying to change the way it thinks. And it’s a stubborn old thing with lots of inertia to overcome. So start small – one team, empowered to work differently.

It’s highly likely that an organisation still working in the ‘old way’ I described will not have good practitioners in user research, product management, design, content, agile delivery and so on. So to begin with you’ll probably need to bring in experts from outside who can demonstrate what good looks like in each of the necessary disciplines.

These experts should want to transfer their knowledge to suitably adept people already in your organisation as quickly as possible, then either join your organisation permanently or get the hell out. Any ‘expert’ who keeps all the secret knowledge to themselves and wishes to feather their nest for as long as possible should be unceremoniously removed from the organisation as quickly as possible.

Don’t focus on processes as these are not what drive success in themselves. Rather the processes will emerge naturally as people in the organisation realise that to achieve the desired outcome, they need to work in a different way. And sure, you can draw on existing methodologies when appropriate to do so, but this needs to be done with the understanding of their underlying principles, so you can have the knowledge to apply the right tool for the job.

Lesson #3 – change is fragile #

The third lesson is that transformation of this kind is fragile and has the potential to be derailed if it’s not shielded from attack, even when it’s been working well for a number of years. You need a suitably-senior champion to cheerlead, defend and occasionally apologise for you, while you and your team get on with the task of learning and sharing a new way of working as you go along.

As you can imagine, there’s plenty more I could talk about on the points above, and loads that I’ve not even had space to mention yet. Thankfully, all of this is not locked up in my head. There’s a lot that you can learn from reading the various government technology blogs and the Government Service Design Manual. It’s not that GDS, MoJ and other government departments have been the first organisations to work in this way (far from it), but they have done an exceptional job of sharing what they’ve learned.

I hope all of that is useful. Let me know if I can help further.

Cheers,

Jock

Agree? Disagree? Join the conversation: