Improving delivery for GOV.UK Design System
Through late 2023 to early 2024, we worked with GOV.UK Design System to double their release frequency, significantly improving service delivery speed and team morale. Facing challenges with traditional two-week sprints, we implemented a new 4-week delivery cycle that fundamentally shifted their approach to rapid iteration and adaptation.
The problem
GOV.UK Design System’s mission is to provide reusable components and patterns for government services, ensuring they are usable, accessible, and cost-effective.
However, this requires constant iteration and evolution. As technology advances – mobile devices, accessibility standards, and user expectations – the design system needs to adapt at the same pace. Traditional two-week sprints had become tiring and sprint goals often missed, resulting in a slowing down of software releases.
This meant the design system often struggled to keep pace with users’ needs for modern, up-to-date components and patterns.
The approach
Recognising this challenge, we adopted a strategic shift towards designing a new delivery model that focuses on delivering value to users, creating space for deep delivery work and learning. This wasn’t just about creating more time for design and development, we also introduced more feedback loops and chances for useful critique.
Traditional two-week sprints and Scrum provide good training wheels for teams who are new to agile, but those don’t work for well established or high performing teams.
For research and development work (like discovery and alpha), you need a little bit longer to get your head into a domain and have time to play around making scrappy prototypes.
For build work, a two-week sprint isn’t really two weeks. With all the ceremonies required for co-ordination and sharing information – which is a lot more labour-intensive in remote-first settings – you lose a couple of days to meetings and workshops.
Sprint goals suck too. It’s far too easy to push one along and limp from fortnight to fortnight, never really considering whether you should stop the workstream. It’s better to think about your appetite for doing something, and then to focus on getting valuable iterations out there rather than committing to a whole thing.
So we designed a new delivery model to help remove some of these issues.
A new delivery model
The new delivery model is a 4-week cycle split into 3 weeks of delivery or R&D, and 1 week of reflection and planning.
You can see how it works in detail on the GOV.UK Design System’s team playbook and in a blog post from the team’s delivery manager, Kelly.
There are a few principles that make this method work:
- Fixed time, variable scope
- Think in iterations: vertical not horizontal slices
- Each cycle ends with something shippable or showable
- R&D cycles end on decisions around scope
- Each cycle starts with a brief, but the team has autonomy over delivery
This gives space for ideas and conversations to breathe, for spikes and scrappy prototypes to come together, and for teams to make conscious decisions about scope and delivering value to users.
The key principle is ‘Fixed time, variable scope’. Teams must end each cycle by either shipping something valuable to users or sharing insights from testing or research. This is what maintains the pace of delivering value consistently.
Making it work
Implementing this new delivery model required close collaboration with other team leads, specifically the delivery manager, Kelly. And it also required a lot of trust from the team to experiment with a new method and reflect on the outcomes.
In late 2023, we co-designed the new model with team leads, presenting the principles that would make it work and discussing the activities that would embed key behaviours.
After presenting it to the team and getting their buy-in to experiment with a new way of working, the team set off on trying out the new model.
The impact
In their first cycle, the team delivered three out of five briefs – a significant improvement on their completion rate at the time. As Kelly reported, ‘most team members enjoyed working in smaller, focused groups and having autonomy over how they deliver their work.’
A few months later, we analysed how often the team was releasing new software: they were releasing twice as often in half the time. Between October 2022 and October 2023, there were five releases. Between October 2023 and March 2024, there were 10 releases.
Here’s a graph showing releases per quarter, based on the dates of releases of GOV.UK Frontend (their main codebase). (Data collected 28 January 2026.)
One year on and the team has maintained momentum. Iterations have increased, they’ve built a steady rhythm of releasing GOV.UK Frontend more frequently, and according to a recent review the team is a lot happier due to increased autonomy and reduced frustration with outdated methods.
Want to try something new?
If you’re looking to increase team happiness and effectiveness, look at our services for reviewing your product operating or delivery model and catalysing delivery teams.