3 ways to master agile delivery in government
We work with organisations across the public sector to design, build and sustain secure user-centred digital services.
Through this experience, we’ve learned a lot about the risk and nagging doubts you’re likely to encounter in service design and creation. Of course, we all know the different stages of a government agile project — discovery, alpha, beta, and live. At face value, the path forward is clear.
But anyone who has worked on a design project will know that there are still many challenges and questions that arise at the beginning of this agile government project lifecycle. So what’s the best way to successfully navigate your way through these areas of ambiguity?
We recently created an ebook to share the methods we’ve learned for making better, more informed choices at key stages that will help you create maximum value for users.
We cover three key areas:
1. How to get user research right
It’s common for people in project teams to hold different views about what good user research looks like and even how it should be carried out.
To get to the best outcomes, it’s important to help all those stakeholders understand the value of research and the methods that are most helpful at different phases of the an agile project.
In the ebook we share seven golden rules that help to ensure that happens.
Put together, these rules help to establish clear expectations for research across all stakeholders… and just as importantly, avoid the temptation to use research to confirm pre-existing assumptions.
2. How to master ambiguity in alpha
When you’ve completed discovery, you’re ready to move to alpha. But as GDS puts it, the reality is you’ve only established whether “there is a viable service you could build.” The key word here is ‘could’. During an alpha, you still need to test the riskiest assumptions unearthed during discovery.
Living with this ongoing ambiguity is an essential part of service design and product management, so we’ve also outlined how we approach this and build the confidence that helps teams move forward. We’ve included advice on how to identify the risky areas on real projects, together with some examples of how we’ve applied elements of this approach to real digital public service design projects.
3. How to unlock success through sustained technical input
When you move from alpha to beta, the solutions architect plays a prominent role – driving the developing Proofs of Concept and the move to technical build.
However, it’s also important to remember that they should also add significant value to the design development process well before we get to that point. From pre-discovery through to beta, we look at where that value comes into play and the dangers that crop up when technical input is missing earlier in the process.
Throughout the ebook we acknowledge that problems are not always easy to solve, and that there is rarely a single ‘right’ way. But by sticking to some fundamental principles together we can succeed.
Download your copy of the ebook
-
How Zaizi’s user-centred approach won the trust of border officers
-
Does the state need to be more like a start up?
-
How to kickstart AI projects in government — lessons from Border Force, HMRC and GIAA
-
My first Regional Scrum Gathering in Stockholm – key takeaways
-
Transformation Day – How do you fit a square peg in a round hole?
-
How product management improves public sector digital services
