A question of agility

Chris Hesketh Chief Technology Officer at BAE Systems Applied Intelligence for the Central Government Client group 27 February 2020 Read time: 3 mins

Government IT is on the move. Chris Hesketh explores why Agile by Design is finally taking root across public sector organisations

Thomas Jefferson once said that “with the change of circumstances, institutions must advance also to keep pace with the times”. The quote, which can be found on the fourth panel of Washington DC’s Jefferson Memorial, remains as pertinent as ever.

Unfortunately, at least when it comes to deploying the power of technology, it remains easier said than done. Although governments should be applauded for using digital advances to develop more user-friendly public services – just the other day, for example, I renewed my passport online – it remains the case that increased IT spending offers no guarantee of improved performance. Money – in this case at least – does not always talk.

As a consequence, Agile by Design has long found favour amongst IT professionals – and why not? After all, it sounds great. It’s hard to argue against an approach which uses sound architectural design and build principles to enable the rapid delivery of new capabilities and ongoing adaptation of government services.

So, why haven’t they always been doing it this way?

Beware the barriers

Being an astrophysicist at heart, I’ll always try to pivot back to the universal laws of science, in this case computer science combined with the political realities of project and programme delivery in the UK’s public sector.

Firstly, when it comes to an IT system the requirements always change. One common reason, is that new users and experienced users have different requirements. The first day you use a system you want it to be big, shiny and fool-proof but in six months’ time, you’re likely to prefer it to be quick and streamlined. As soon as you start using a solution you start requiring something different from it. A bit like quantum measurement theory, where you can’t measure something without impacting it, you can’t introduce an IT system without impacting the requirements it was built for. So change, at least in part, is inevitable.

Secondly, just like the dark matter in the universe, an IT system is mostly made up of logic to prevent the wrong thing from happening. For every functional behaviour you want to see, there are many more exceptional conditions you don’t want to see that need to be addressed. For example, when pressing a button a user might just want a light to go green, but what happens if it is pressed twice, or by accident, or the bulb is blown? This isn’t a problem in itself, but it means that design and development is always harder than you or the customer would like to pay for.

Thirdly, IT systems are inherently non-linear – chaotic, like the weather and the butterfly effect. This is because there is no engineering tolerance in an IT system to absorb mistakes; every bit has to be right – changes in one side of the system can lead to catastrophic failures on the other side. The building I’m sitting in as I write this had a blueprint which its builders could follow down to pretty much the last millimetre – but even if they were a bit further out it would still plug together. An IT system, by contrast, has no inherent tolerance whatsoever.

And finally, an IT system needs a computer. A simple universal law. Physical platforms and environments have traditionally been built in a waterfall fashion and involving millions of pounds. This, perhaps unsurprisingly, has limited the options for new ways to achieve successful delivery and transformation.

Taking root, taking off

The first law means change. For decades we have known that the correct response to change has been increased agility. So if Agile by Design is finally trending across government then it must mean we have better solutions to the other laws, the ones which make being agile hard.

For me I think the most salient ones are:

Micro-services are better at encapsulating change – which means that if and when something goes wrong, the impact is minimised.
Continuous integration and deployment pipelines have shrunk the IT release cycle so that changes can be smaller, safer and more frequent.
And of course, with infrastructure and network elements now available on demand, the need for a waterfall project plan, once so ubiquitous has been washed aside (forgive the pun).

This means we can finally focus on the hardest and most pertinent challenges: delivering what the user needs now and being able to adapt to as that inevitably evolves.

Is this easy? No, of course not, but at least now we have a fighting chance of keeping up.

Learn more about Agile transformation in the public sector

Find out more

About the Author

Chris Hesketh is the Chief Technology Officer at BAE Systems Applied Intelligence for the Central Government Client group

chris.hesketh@baesystems.com

Further Reading

Going Digital is one thing, Transformation is quite another. Mivy James explains why genuine transformation requires far more than just digitising outdated processes
Making the Ministry of Defence more Agile. Agile working is by no means limited to the private sector. Continuing our series examining transformation, Mivy James sits down with the MoD’s Adrian Bailey to talk process, product and pace
Adapting for Agile: Lessons from the frontline. Changing how an organisation works is not for the faint-hearted, says Iain Abernethy. Here, he shares a few lessons from years on the Agile frontline
Delivering digital change in Defence. Continuing our examination of Agile working, Kevin McLeod spotlights the technological whirlwind reshaping the UK’s Defence sector. But with change comes challenges...
In control with Agile. Jenny Matthews explains how Agile working can give you the control you want, without having to compromise