Citizens can get the information and services they need more quickly because users' needs are considered in government service design, and suppliers can work with the government in modern agile ways: these are two benefits resulting from the UK Government’s digital transformation. Having teams exposed directly to users motivates teams to make their products better.
James Stewart, partner at Public Digital, presented the UK Government’s digital transformation journey at Agile Summit Greece 2018. InfoQ is covering this event with summaries, articles, and Q&As.
The key to the digital transformation was in the "default" part of "digital by default". Instead of online channels being an optional extra, we worked to put the culture, processes, practices, and technologies of the internet at the heart of how services are conceived and delivered, said Stewart, a massive change in how the UK government shapes policy, how it understands what citizens need, and how it measures its performance.
The UK government’s transformation raised the expectations among the public and civil servants of what a government can achieve when it works digitally, which may be the most lasting legacy in the UK and around the world, argued Stewart.
InfoQ interviewed Stewart about what it was that made the transformation a revolution, the main challenges they had and how they dealt with them, the benefits that the digital transformation delivered, and the lessons learned.
InfoQ: Your talk’s title mentions "Revolution NOT Evolution". What was it that made it a revolution?
James Stewart: The title is taken from the 2010 review by Martha Lane-Fox that led to the creation of the Government Digital Service (GDS). The vision presented there was of shifting government to a service culture: one that put the needs of citizens above the bureaucratic structures, and one that embraced internet-era ways of working rather than the 19th century processes that shaped most modern governments.
InfoQ: What were the main challenges and how did you deal with them?
Stewart: I worked in government for six years and the challenges kept changing as we went on. One of the biggest initially was learning to deal with the mythology that defined how many processes worked. In any organisation that’s been around for a while, ways of doing things build up and often disconnect from the reasons they were put in place. Things are cited as "rules" which are really just norms. We had to get really good at working out the difference, and on pushing back on some of those rules to get to the core principles.
For example, some people said that you couldn’t ask technical questions in interviews or deviate from a script if a candidate said something you wanted to dig into. That’s not the case, as long as you are confident that you’re giving every candidate an equal opportunity to prove themself, are consistent, and keep good records. We got really good at doing the research and pushing back so that we could change the practices without compromising the (often very sensible) principles.
As time went on, though, the bigger challenges revealed themselves in the funding, governance and power structures of government. You can get a certain way into providing better services, improving technology, introducing new skills without addressing those big parts of the system. But at a certain point you have to fix the systemic things if you want to really take advantage of internet-era ways of working. And that’s when you run into real resistance as you’re challenging the things people have spent entire careers defending. We got a certain distance with that and really successful common platforms like GOV.UK Pay and GOV.UK Notify are the evidence of that, but much deeper institutional reform is still needed.
In the InfoQ article Agile in the UK Government - An Insider Reveals All, Nick Tune mentioned that not assessing full end-to-end systems poses major challenges for the front end teams to deliver:
What shocks me the most about the conflicting digital and IT silos is that GDS don’t seem to assess any of the backend systems, in my experience. They expect digital teams building the websites to work in an agile way, focusing on users and open sourcing their code, but I never saw the same standards being applied to the internal IT teams who manage all of the backends. I know of one government project where the digital team couldn’t even add one extra textbox to their address fields, something users were complaining about, because the backend IT teams were too busy to make the change.
InfoQ: Which benefits did the UK Government’s digital transformation deliver?
Stewart: The headline is that it saved £4.1bn over three years, but the reality is that we achieved that by focusing on deeper benefits. Millions of people can get the information and services they need more quickly; there are teams across government who are equipped to what their users need and how and when they need it and to continually improve services; and there’s a whole new set of suppliers who can work with government in modern, agile ways.
Tune described in his InfoQ article what is done to assure that users' needs get high attention:
IT projects in the UK government must follow an approved GDS format. During each phase of the lifecycle you have to personally demonstrate to GDS that your team has understood who your users are, what their needs are, and how the system you are building addresses those needs.
InfoQ: What lessons did you learn on your transformation journey?
Stewart: So many lessons! Some of my colleagues set out to document the higher level lessons. The result was an entire book -- Digital Transformation at Scale: Why the Strategy Is Delivery -- but there’s a huge amount more that couldn’t be included there.
But top of the list is the importance of remaining focused on your purpose and your users’ needs. As technologists and agilists we can too easily be drawn into improving technology or simplifying processes without stepping back and asking why we have those things in the first place, or if the change we’re making is the right one.
I’ve talked to a lot of teams in large organisations who have taken all the right steps in moving to agile but are still having trouble motivating their teams, and the missing piece is almost always being exposed directly to your users. Whether they’re end customers, or internal users, there’s nothing like seeing people use your products to motivate the team to make them better.
Beyond that, a thing I’ve spent a lot of time on recently is looking at the way finance works (or doesn’t) in a continuous delivery environment, the result of which was a paper for the AWS Institute - Budgeting for Change - writing that was yet another reminder of the importance of a genuinely inter-disciplinary approach. I worked with a public sector finance specialist and learned a huge amount in the process. Revolutionary change requires engaging with all angles of the way we do things, always with a team that can apply as broad as possible a range of perspectives and skills.
Earlier InfoQ publications explored how the UK government uses cloud computing, DevOps at the UK government, Agile in the UK government, open source development at the UK government, and DevOps at UK’s Department for Work and Pensions.
