Our working style and culture is based on the proven Agile project management approach and principles.
We do this as agile methods encourage teams to build quickly, test what they’ve built and iterate their work based on regular feedback.
What is agile?
Agile started out as an alternative approach to software development, but is now applied more widely to running other types of projects and products.
The principles behind agile are set out by a group in 2001 in the Agile Manifesto. They can summarised as:
- User need is our highest priority – at every stage of development
- Changes and improvements are encouraged throughout every stage of development – even very late in the project
- Developments and improvements are managed within short and regular timescales – ideally every two weeks
- The project team must work hand-in-hand with the experts and service professionals – at every stage
- The team should be constructed of motivated individuals – within a supportive and trusting environment
- Face-to-face conversations and engagements should be held regularly – with everyone on the team
- A working product is the primary measure of progress – good enough is good enough
- Processes should be sustainable over the longer term – a steady and regular pace of delivery
- Good design and usability need to continuously considered – it keeps the product agile
- Simplicity is design and functionality is the goal – remove unnecessary complications
- The team will self-regulate itself – be the culture we want to see
- The whole team seeks continuous improvements in everything it does – even in the way the team operates
You can find out more about he Agile Manifesto at www.agilemanifesto.org.
Why agile is good for us
While historic sequential and process driven project management approaches have often been seen as necessary to build and develop public services, they are less effective for building and running services when technology changes quickly.
Local services also need to be able to respond quickly to policy changes and the needs of the public. With regularly changing service providers, eligibility criteria and expectations, using agile methods allow us to quickly make any changes while we’re building the content, and also when it’s live on our website.
Using other historical methods of project management means that we may spend 18 months building a service that no longer meets our policy, can’t work with the latest technology and doesn’t meet users’ needs. We know, we’ve been there.
Our culture is designed to stop this happening.
Phases of an agile project
Our agile project approach can be broken down into five separate, but interlinking, stages:
1. Discovery phase
Before we start building a service, we need to find out whether users need it and whether other services exist.
2. Alpha phase
Alpha is the development phase that comes after discovery.
In the alpha phase we need to:
- build prototypes of our service
- test our prototypes with users
- demonstrate that the service we want to build is technically possible
3. Beta phase
The objective of the beta phase is to build a working version of the service based on our alpha prototypes. The version we build must be able to handle real transactions and work at scale.
We also need to keep improving our service and replace existing services or integrate with them.
4. Live phase
The live phase is the time to keep improving our service based on:
- user feedback
- our ongoing user research
5. Retirement phase
Our service may eventually need to be retired, for example if policies change or if there’s evidence that users’ needs have changed.
When retiring a service we must consider user needs in the same way we did when we built the service.