Agile delivery phases
In 2011, the UK government established the Government Digital Service (GDS) to implement the ‘Digital by Default’ strategy proposed by Martha Lane Fox. GDS and the ‘Digital by Default’ strategy intended to revolutionise the way citizens interact with public services and government departments. Central to GDS’ approach is the Service Manual. The Service Manual provides guidance and support to public sector organisations for creating and running better digital services.
The Service Manual describes how an agile approach to delivering projects can lead to better digital services.
The core principles of an agile approach are:
- Focus on user needs
- Deliver iteratively
- Keep improving how your team works
- Fail fast and learn quickly
- Responding to change over following a plan
The Service Manual describes four stages of agile delivery:
- Discovery
- Alpha
- Beta
- Live
Discovery #
Before committing to building something, we need to understand what the user needs are and if a new thing is needed. This is discovery.
Discovery de-risks the future. It allows us to understand the scope of a problem and the best way to proceed in response.
Activities in discovery include:
- User research
- Analysis of business needs
- Market research
- Journey mapping
- Cost analysis
We are not building software in discovery. The outputs of a discovery include:
- Recommendations on the best way to proceed.
- A prioritised list of user needs that future development work can be planned against.
- Findings about current processes or the existing service.
- Estimated scale and costs for developing a new service.
Alpha #
After committing to building a new service, we need to understand how it will work for users and how it will integrate with existing processes and systems. This is alpha.
Alpha results in a better and more focused service. It allows us to understand how users will interact with the service and what is technically possible.
Activities in alpha include:
- Building test designs or concepts
- User testing
- Service design
- Technical audit and exploration of existing and legacy systems
We are usually not building software in alpha, even though it might look like it. The outputs of an alpha will include:
- Designs that have been tested and iterated with users.
- A roadmap and plan for a beta phase.
- Metrics to measure performance.
- Research findings in the form of user stories and journey maps.
Beta #
With a clear scope, user needs, and technical approach in place, we are ready to build a working version of the service. This is beta.
Beta results in software that can handle real transactions and is ready to work at scale. It allows us to develop better services that meet user needs.
Activities in beta include:
- Developing working software
- Testing and iterating
- Getting the service accredited
- Measuring performance
- Developing and testing a security approach
We are building software and technical infrastructure in beta. The outputs of a beta will include:
- Working software that is being used for real transactions
- Technical infrastructure to support the new service
- Metrics about the performance of the service
- A backlog of development tasks for ongoing iterations
- An approach for security
Live #
Once a service is being used for real transactions, continuous improvements can be made based on feedback, research and data. This is live.
An active digital service is never ‘done’. The live phase allows us to respond to change and new research findings in order to keep iterating the service.
Activities in live include:
- Iterating and improving the service
- Measuring performance
- User support
- Testing the service for security
We are continuously improving and supporting working software. The outputs of live will include:
- Iterations and improvements to the service
- Metrics on performance
- A backlog of development tasks for ongoing iterations
- Security tests
Adapting our approach #
Clients have different ways of working. They may not be familiar with the Service Manual. Or they may have a slightly different approach to agile to us.
The principles behind the Service Manual should be consistently applied in any project we deliver. But this doesn’t mean we need to follow a rigid, gated process to get things done.
We can support our clients by:
- Explaining the content and value of the service manual
- Helping them understand terminology such as “sprint ceremonies”
- Coaching them to think about user needs, lead ceremonies, or work openly
- Helping them to apply the principles of the Service Manual in their own context
Last updated: 14 June 2024 (history)