Agile Project Delivery
Agile Project Management methods encourage teams to build quickly, test what they’ve built and iterate their work based on regular feedback. There are many agile methods you can use when building a service, each has its own set of tools and techniques.
Where Did Agile Come From?
Agile started out as an alternative method to develop software, but is now applied to running other types of projects. The principles behind agile are set out in the Agile Manifesto (2001).
Why Agile Is Better For Services
While a sequential waterfall approach is necessary to build things like bridges and buildings, it’s less effective for creating and running services when tech changes so quickly. That is where Agile Project Management comes in.
Agile Project Management Phases
Alpha, Beta, Live and Retirement.
Before you commit to building a service, you need to understand the problem that needs solving.
That means learning about:
- your users and what they are trying to achieve;
- any constraints you would face making changes to how the service is run – for example because of tech or legislation;
- the policy intent you have been set up to address – this is the thing that the user wants to change or make happen
- opportunities to improve things – by sharing data with other teams for example.
This part of your project is called the discovery phase.
Alpha is a chance for you try out different solutions to the problems you learnt about during your discovery. Spend alpha building demos and testing ideas. Don’t be afraid to challenge the way things are done at the time: alpha is a chance to explore new approaches.
By the end of the alpha phase, you should be in a position to decide which of the ideas you’ve tested are worth taking forward to beta.
The beta phase is where you to take your best idea from alpha and start building it for real. It also involves thinking about how your service will work with (or start to replace) existing services, and preparing for the move to live phase. Structure your beta phase so you can roll out the service to real users – with minimal risk and maximum potential to learn and iterate the service.
- the service team has the capacity to sustain that learning and iteration through the beta period
- support staff are able to cope with new users who might struggle to use the service in ways you didn’t expect
You’ll start out in ‘private beta’ this involves inviting a limited number of people to use your service, so you can get feedback and improve it. Once you’ve improved the service and are sure you can run it at scale, you assess whether the time is right to move into ‘public beta’.
The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements.
You will also:
- continue to address any constraints you identified at beta phase
- continue to develop the service and work with others providing services that are part of the same journey, so that you are iterating towards solving a whole problem for users
- transition or integrate any existing transactions that meet a similar need to yours – making sure that what you end up with has a scope that makes sense to users
You will have your live assessment from the end of the public beta phase. Spend public beta preparing for live phase.
Your service may eventually need to be retired, for example if policies change or if there is evidence that users’ needs have changed. When retiring a service you should consider user needs in the same way you did when you built the service.
You should have a plan for securing the info you’ve got about your users. You should already have a plan in place to manage that data, including details of how long it will be retained. You must make sure that there is support in place to maintain these policies and protect information.
Other Standards & Code of Practice
Find out more about the standards and codes of practice that White Rabbit follows on the Service Standard page.