Bias for Agile action speeds digital transformation in the public sector

Woman using the computer and 2 other devices sat at a desk

Written by Michael Beaven, Senior Manager, Government Transformation - International, Amazon Web Services

In the UK government, I led the Government Digital Transformation Service (GDS) Transformation Program during a period in which we set ourselves the goal of digitally transforming 25 citizen services in 400 days. We used an Agile approach to modernize a range of services, from social care benefits to prison visit booking. By the end of 400 days, we had transformed 20 of the original 25 planned, and in their first year, these services handled more than 175M citizen transactions. Now, as a government transformation lead at Amazon Web Services (AWS), I also work with the AWS Institute executive education program to teach public sector leaders how to accelerate and expand their impact for citizens with digital transformation.

In this blog post, I share my experience using the Agile approach to transform government services, and offer some best practices for organizations who want to adopt a bias for Agile action to deliver successful modernization faster and at scale.

 

What is the Agile approach?

Agile is an iterative project management approach in which teams deliver value to stakeholders early and in smaller increments by breaking up large projects into smaller phases, and then refining their process and products based on feedback to these smaller launches. By contrast, traditional models of project management typically approach product development and launch in a linear way, with complete delivery of final products to stakeholders at the end of a pre-determined period. Originally, Agile started out as a method to manage software development, but has become widely adopted across industries and the public sector as a way to innovate in an environment of rapid technological, social, economic, or other change.

In the Agile approach, organizations can win trust with their stakeholders and end customers as they show results over the course of the project. I saw this when I worked on the Digital Transformation Exemplar Services project. Agile lets you learn lessons in real time, which saves time and money as you don’t wait for the final product to deliver and then rework it. In an iterative process, you also find out what is not working quicker. Delivering smaller wins on a project in phases with Agile helps your team build momentum as you win stakeholders over to your transformation cause.

 

Test risk early and often

Large organizations typically have more traditional governance models and approaches to risk management that can be a challenge to reconcile with the Agile approach. These organizations can be good at relying on what worked in the past, which can lead to using a risk management solution like risk registers that can create a false sense of certainty. In a traditional project planning phase, for example, a team may predict that a linear message queuing system might fail if demand peaks, put that prediction on their risk register, and then move ahead with developing that system anyway. Using an Agile approach, when you predict a risk, you test for it against an alternative to mitigate predicted risks early, well before launch.

 

Iterate with real users to deliver the right services the first time

When I worked on the Digital Transformation Exemplar Services project in the UK government, my team started working with a particular benefit called Carers’ Allowance. To earn trust with the team delivering the allowance, my team and I went onsite and sat with the people processing claims so that we could really understand their challenges as they worked to implement the service. We also talked to the claimants themselves to truly understand how the service performed for the end customer. One mother who was caring for her disabled child told us that each time she had to fill out the form, it took her back to the moment the doctor first told her of her child’s disability. Ultimately, this and our other insights – formed through being open to Agile ways of working – helped us transform the user experience, both for internal stakeholders and the end customer.

Another benefit to this part of the Agile process is that by showing results based on listening to feedback, you win stakeholder understanding and support. One of the most important lessons we learned while working on the Digital Transformation Exemplar Services project was how to help stakeholders by focusing on the data and the lived customer experience, instead of developing and deploying a pre-determined solution that may or may not fix the core challenges the service was meant to address.

 

Manage stakeholder communication

Success with the Digital Transformation Exemplar Services project was mostly due to the good relationships we established between the product managers leading the build and the senior stakeholders in the departments we worked with. We agreed on road maps with target dates and milestones to show results along the way; we supplied real data to support what we were doing; and we had tough conversations. When we had successes, we celebrated those by communicating them clearly.

One of the key responsibilities of those doing transformation work is to learn to communicate in the language of your stakeholders. Find out what words they use to describe their meetings, their groups, and their governance structures. Then mirror some of that in the way that you talk about Agile. Hold on to your purpose, and do not compromise on that, but be willing to change how you speak about your program so you communicate new concepts in a way your stakeholders understand. When you’re asking people to do something different, it’s important to take the time to explain how it will deliver value. Then the faster you can show real results, the easier it is to win their confidence and support, and you can build momentum.

 

Don’t get stuck iterating

In my experience in the UK government, we avoided endless rounds of iterations by being disciplined about moving on. We’d get to a stage when we had enough good user feedback to tell us we were on the right track, then we’d progress. As Rose Mortada, service owner at the UK Ministry of Justice, explains in the Bias for Agile Action video, you should not do discovery for more than four to six weeks; after that, you need to move on to the next stage, which is to build and test your prototype.

 

Learn more about public sector digital transformation

I champion the Agile approach with public sector leaders in organizations of a variety of sizes, and I’ve seen it work in many different settings. You can learn more about digital transformation for public sector leaders in the no cost AWS Institute Executive Education global program. Discover more about government transformation and how to get involved in the executive education program at the AWS Institute.

 

Find more insight about successful public sector modernization in the AWS Institute quarterly newsletter.


More thought leadership

Comments are closed.