You must use an agile approach to project management to build and run government digital services.
Agile methods encourage teams to build and release quickly, test what they’ve built, and iterate their work based on regular feedback.
Core principles of agile
There are different agile methods you can use, but you should always follow these core principles:
- focus on user needs
- deliver iteratively
- keep improving how your team works
- fail fast and learn quickly
- keep planning
Focus on user needs
Agile is about constantly putting your users first. You must prioritise their needs over everyone else’s, including those of your senior stakeholders.
Why user needs matter
If you start building your service before you understand who your users are and what they need the service to do, you risk:
- building something that nobody needs or wants
- trying to solve problems that aren’t important to users
You need to ask for your users’ feedback early and often, and listen to them – even when they tell you things you disagree with or don’t want to hear.
You should always use data from real people who are using your service and let it influence the direction of your project (see Digital Services Factory data protection guidelines for user research activities for more details).
Keep improving your service
To work in an agile way, you must continuously improve your service and its features – this is sometimes called ‘iterating’.
Every service is different, and building a service is a process that involves a lot of decisions made over time but, in general, follow these steps:
- Build something that meets the need that’s most important to your users.
- Show it to your users, listen to their feedback and improve it.
- Repeat this process to meet the next most important user need.
Agile is about making the complex process of building a digital service as simple as possible. It’s based on improving what you do day by day and week by week.
Why you need to keep improving your service
The process of producing incremental, production-ready features allows you to:
- give value to your users and stakeholders regularly
- shorten feedback loops that could be longer if using a waterfall methodology (where you only seek feedback when the final product is complete)
- decide the features you want to add next
- spend time creating features that your users care about
- make sure everything you build is accessible and secure
Keep improving how your team works
As well as improving your service gradually by talking to your users, talk to your team to keep improving the way they work, so that:
- the team learns and improves throughout the life of your service
- the quality of your service improves, saving you time, effort, and money
Find out what’s not working
Talk to your team to find out what’s working and what needs improvement, for example, in your team’s daily standup or regular retrospective (both core agile practices).
You should try to discover:
- any problems the team is having with absolutely any part of the work
- anything that’s stopping the team from getting work done or delaying work
- any problems individual people have
Fix the problems
Once you’ve found problems, you should agree on a way to fix them as a team. Sometimes these problems aren’t related directly to the service, but issues that might affect how a team delivers (for example, an issue with an existing policy or process within the department). Product managers should work with their service owners to try and address these problems too.
Use standups and retros to see if what you did fixed problems the team talked about at previous meetings.
Fail fast, learn quickly
Agile techniques don’t guarantee success, but you don’t have to be afraid to experiment, as agile allows you to spot problems early and resolve them quickly. You should learn to fail and create a culture that learns from failure.
You can prevent major issues from happening by:
- demonstrating value to your senior stakeholders (for example the senior responsible officer, director, or deputy director) with regular releases
- releasing regularly to prevent creating a ‘too-big-to-fail’ service that shouldn’t be released, but must be released anyway
- using processes like test-driven development and automated testing (writing tests before you develop the features to be tested) to highlight issues with quality early on
- identifying important metrics, establishing a baseline, and monitoring for changes throughout the project
Regularly releasing and testing small features with your users:
- improves quality
- improves visibility
- reduces cost
In an agile project, you should continuously plan based on data, usage patterns, and new requirements from the service you’re trying to replace.
Your team should plan together and review these plans regularly based on:
- your progress
- any new facts and requirements
You should communicate with stakeholders about any major changes to your plans, or the impact that any new requirements will have on delivery.