You don’t have to do fortnightly sprints
In early 2024, we helped GOV.UK Design System design and implement a new model for agile delivery. It was a break away from traditional Scrum and two-week sprints towards an emphasis on iteration and reflection.
Why change things?
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 with two-week sprints.
Sprint goals suck too. It’s far too easy to push it 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.
How it works
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’s also a graphic that brings the four-week cycle to life.
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.
How did it work out?
In their first cycle, the team delivered three out of five briefs – which was higher than 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.
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 working that way.
Want to try something new?
If you’re looking to increase team happiness and effectiveness, drop us a line and we can chat about transforming your team’s delivery model too.