You hear the word agile in government a lot these days. And not only within the teams making digital services.
Agile development is a way to make software. We build a simple prototype quickly, then keep improving it by releasing frequent updates. You can read more about it in the agile manifesto.
We're using agile development to build digital services throughout government. The Office of the Public Guardian used agile methods to build the digital service to make a lasting power of attorney.
As you might guess, the service makes it much simpler to make a lasting power of attorney. Instead of filling out long paper forms, the service asks you a series of questions, and fills in the forms for you. You simply sign and post them back. It’s a great example of agile development delivering a service that can make things easier for millions of potential users.
The other day, we put a video camera in front of the Public Guardian, Alan Eccles, and got him talking about agile development. I think it's fair to say he's a fan. Anyway, here's the film of what Alan had to say:
It’s interesting to hear is how agile methods have influenced the whole culture at the Office of the Public Guardian. But it takes time to adjust. To begin with, words like alpha, beta and live can be alienating. At GDS, we can help people by talking to them, and pointing out relevant bits of the Service Manual.
And if you're very interested, here's a longer version of the film.
Here's the transcript:
Public Guardian Alan Eccles talks about his personal experience of using agile software development to create the online lasting power of attorney service https://www.gov.uk/lasting-power-of-attorney
The Public Guardian on agile development
Agile development involves building a core digital service quickly and then continually improving it to make it better
Alan Eccles, Public Guardian for England and Wales:
The key thing about agile is it not only puts the customer in the heart of what we’re doing, but actually puts the customer in the place of driving development. It’s about breaking down those customer expectations into small chunks so you can deliver something that they’ve asked for really quickly. You can say, “Is this what we expected? Is this what you were looking for?” It’s open, it’s transparent.
The two-weekly sprint and the continual iteration of what we’re doing has worked particularly well. That’s helped us to see a product emerging, and for us to be able to shape it with the developers, and we’ve moved from process to customer outcomes, so we no longer measure how quickly we move the piece of paper, but we measure what the impact is on the customer.
Doing something in an agile way doesn’t mean you’ve thrown governance out of the window. In fact I feel that I’ve got more control over an agile development, because I see what is being done, or have the potential to see what’s being done, once a fortnight, I can say whether I like it or not, and I can stop things really quickly if they’re not going right.
I’ve had to learn a whole new language about discovery, alpha, beta, live, scrum – so it’s learning what that actually means in practice and bringing it alive to other people.
It’s changed the language of the organisation. It’s quite interesting just to overhear conversations even in the office for people who aren’t in the digital team, talking about, “Well, before we start off on this project, what’s the minimum viable product here we want to deliver?” Also people talk about iterating customer delivery and services and processes, so it’s got into the psyche.