IBM's Jeremy Worrell argues that the public sector should beware the "agile" smokescreen


The public sector should take care to avoid inviting chaos in Digital and ICT.

What? Why would they do that anyway? What’s he talking about?

Fair questions. But it’s already happening.

Widespread frustration with a legacy of inflexible methods and contracts has produced a groundswell of support for Agile thinking. In Agile, we reject the idea of spending months in tortuously gathering and approving requirements, and instead concentrate on delivering real working solutions in short timescales … then iterating to continuously improve them.

To people steeped in “waterfall” delivery methods, this will sound somewhat sophisticated, and rather revolutionary. But of course it’s nothing of the kind: It’s just how problems used to be solved before some bright spark invented waterfall!

Agile is how we solve problems in real life too. Rarely do we expose a problem to intense, chronic scrutiny and analysis before taking some practical steps to improve things. It’s usually the case that speed is valuable to us, and that procrastination will mean the situation changes anyway. We’re prepared for small missteps because they can easily be unpicked with limited residual damage, and they will better-inform us about what we really need.

So I’m not criticising Agile. As someone who has been deeply exposed to it recently, I find myself a big supporter.

What really worries me is the “Agile smokescreen”—a way in which I now see dysfunction legitimised, and value demoted. I’m sure this is NOT what the Agile Manifesto intends! Chaos is not the right answer.

Have you seen this smokescreen in action? Would some examples help you recognise it?

How about the development team which has no vision for its product, and fails to see how it fits into the wider organisation? Instead it looks only to urgent user problems to prioritise activity.

Or what about the rejection of portfolio management, based on the assumption that treating each individual product using Agile methods will somehow address the larger questions about which products to bet on?

And I like the way in which unresolved issues can be buried in immature organisations, by Product Owners saying they’re “on the backlog”. This seems to stop some scrutineers in their tracks, somehow preventing them asking the obvious follow-on questions.

There’s also the evasion of measurement. Agile teams should absolutely measure their “velocity” (AKA efficiency) but unless there’s consistency across the organisation, how can meaningful comparisons be drawn?

And what about risk: Some systems do still warrant waterfall methods (or at least a risk-averse tailoring of Agile ones). For example, if we modernise a legacy system without functional change, then the Minimal Viable Product (MVP) may well be “everything”, and the impact of any omission could be fatal.

So I argue for a structured adoption of Agile, fanning away the smokescreen by giving teams the flexibility they need, but also providing effective oversight.  Frameworks like “SAFe” can help with this.

In a similar vein to my last article, I’d like to see new and established methods evolve in harmony: In the same way that strategy must be layered to accommodate pace of change, so must Agile be adopted inside a system of control.

But what do you think?  Please do contribute your ideas and experiences to the debate.

Jeremy recently took part in a webinar on government digital reinvention, which you can view here
Click here to download IBM's latest report:
Approaching Cloud Computing in Government​

Share this page