Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Core principles of agile
You must build and run your service using agile methods.
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
Meeting the Digital Service Standard
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.
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 which 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
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 save time, effort and money
Find out what’s not working
Talk to your team to find out what’s working and what needs to be improved, for example in your team’s daily standup or regular retro.
You should try to discover:
- any problems the team is having with absolutely any part of the work
- anything that’s stopping the team 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.
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 fail or 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 or failures from happening by:
- demonstrating value to your senior stakeholders (eg 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 and usage patterns 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 may also find these guides useful:
- Published by:
- Agile delivery community
- Last update:
Guidance first published