View our updated agile resource
We've launched a new resource to help you work through each phase of the agile delivery process. Switch to the Delivery Manual for our updated content.
Agile is a form of project management designed to deliver products and services. At the heart of Agile is the idea of failing fast, learning quickly, and adapting.
Agile is a new way of delivering government services that makes it easier and quicker to build the right thing for users.
The ‘service design and delivery process’ is an agile approach that helps us put users at the heart of our work.
It’s important to communicate this new way of working to decision makers and people in our teams. By doing this, we can help everyone understand why we should follow the process.
Traditionally, government has built services in response to policy needs. Teams would capture requirements, get the resources they needed and then would build and launch the thing. User needs would be discovered after the thing was built and finished.
The service design and delivery process changes this to start with user needs. The team continues to research with users through all stages to check they are building and improving the right thing.
The service design and delivery process is an agile approach with 4 stages:
- Discovery stage — the team gets a deep understanding of the users and their needs, and developing hypotheses to solve the problems
- Alpha stage — the team builds prototypes to test the hypotheses
- Beta stage — the team builds and tests a solution based on the hypotheses validated in Alpha
- Live stage — the team is changed to maintain and improve the service
The stages build on each other but they don’t always go in order. Sometimes a service might go back to an earlier stage (for example, if a service in Beta needs to go back to Discovery to work on a different problem).
The first 3 stages of the service design and delivery process are similar to the double diamond phases of discover, define, develop and deliver:
- In the first half of the Discovery stage you go wide with user research to understand the problem (discover phase).
- In the second half of the Discovery stage you narrow in on the biggest pain points to really understand them so you can define hypotheses (define phase).
- In Alpha stage you test your hypotheses using prototypes until you can define a minimum viable product (develop phase).
- In Beta stage you build the minimum viable product (deliver phase).
The Digital Design Standard guides teams as they follow the service design and delivery process.
To get support and budget to work in a new way you need to manage the risks in changing the way things have been done previously.
The service design and delivery process helps you add value quickly and regularly check that you are building the right thing. This reduces the risks around working to a large release with limited research to support it.
Make sure that you understand the organisation's goals. You may need to make a business case that shows how using the process will help you meet these goals (for example, the process will help you build quicker, which reduces the cost of running a team).
Be clear from the start what support you need from other people. This might include the authority to recruit the right roles and capability for the team.
Find out how you need to report on your work. The process uses agile techniques that give you lots of opportunity to show how you are working and produce artefacts to communicate progress.
The service design and delivery process helps teams start delivering quickly. It also helps teams to adjust their work to new information they get about your user needs. This reduces the risk of building the wrong thing.
Other governments, including the UK and the US, are following similar processes to make sure they add value to their citizens.
Deliver the right thing
The process focuses teams on building end-to-end services. This helps users to get things done in the way that suits them best. It also helps users with additional needs to get things done.
Frequent incremental releases increase value for users and give feedback on what needs more work. This helps the team to prioritise its resources so they keep building what users actually need. Releases also become routine for the team rather than major milestones.
Regular showcases of work are built into how teams follow the process. They discover very quickly if something is not meeting user’s needs.
The process is iterative and transparent, with quick feedback loops. Teams learn more about user needs earlier on, and can make better decisions about how to meet them with the available resources.
The process helps teams work in progressive increments designed to meet specific needs. They can test those parts of the service and quickly adjust to iterate them.
The process allows teams to break a large risk into smaller, more manageable risks. Teams tackle the most valuable thing first.
Teams can also test assumptions, especially the risky ones, early. This allows them to make data-driven decisions based on rigorous research.
Teams don’t waste time working towards a big release only to find it doesn’t help users. They know early if something is not going to help users and can pivot.