Throughout January 2015, we gave people in our product and infrastructure teams the freedom to work on anything they liked so long as it was good for GOV.UK.
We called this a “firebreak” - a time of fewer top-down commitments, which people could use to investigate new ideas, clean up technical debt and “scratch their own itches” as one of our developers put it.
A whole team working off-roadmap for a whole month might sound reckless or indulgent. But in fact, it would have been reckless not to.
This post explains more about why this firebreak was important, how we ran it, what value it created, and what we learned about doing it better in future.
Why it was important
The GOV.UK team had just been through an intense period of development: building a single publishing platform for government (a world first!) and moving more than 300 organisations onto it in the space of around 2.5 years.
We were about to enter a new, similarly busy phase: readying the platform for the general election by May, consolidating our applications, and overhauling content, search and navigation now government information is finally together in its entirety.
Between those two phases of work, it was vital to release some pressure from the system. Our people were tired, running real risk of burnout, and the layers of complexity which arise when you build things fast were becoming increasingly expensive to service. To make sure we can do a good job of what’s needed next, we first had to invest a bit of time repairing our people, technology and processes.
More positively, we also wanted to make space to think and try out some ideas which had had to wait while we hit deadlines.
In that respect, GOV.UK’s firebreak was like innovation practices elsewhere - Google’s 20% time (which birthed Gmail), 3M’s time to think (which brought the world Post-Its), Apple’s Blue Sky programme, LinkedIn’s Incubator and Spotify’s regular hack weeks. Great things can happen when you give creative, passionate people the freedom to explore ideas. We’d not been able to do much of that in the past few years, so we wanted to make up for the missed opportunity.
Lastly, we needed to clear the decks. Product backlogs have a habit of growing into lists of way more things than will ever get done, and quickly become albatrosses around a team’s neck. Rather than plugging away at those existing lists, making hundreds of small incremental changes which don’t add up to much, we needed to step back, think and focus on the things that will make the most difference to GOV.UK’s users in 2015.
(True story. Between the beta and live releases of the departments and policy section of GOV.UK, one weekend my delivery manager Pete unilaterally deleted the backlog I had lovingly groomed. I was furious for weeks, but it turned out to be the best thing that happened for the project. If it’s important, it really will come up again).
How we ran it
It all started with asking everyone for their ideas.
At the start of December we set up a whiteboard in the middle of the office with a stack of “idea cards” for people to fill in - folded A5 sheets with checkboxes to indicate what help might be needed from others, and space to sign up inside.
On returning to work in January we held a kick-off event, laying down 3 simple rules:
- essential maintenance and prior commitments come first
- other than that you can work alone or with others on anything which is
- good for GOV.UK; and
- can be done in the time available
- you have to show and tell the rest of the team what you’ve done
We held semi-regular pitch meetings, consisting of 30-second slots where people seeking teams could explain their idea, and people seeking things to work on could hear what was available. Ideas were added and pitched throughout the month, tailing off as we got closer to the end.
We also held frequent demo sessions - twice a week to start with, reducing to weekly.
At the end of the month we closed the firebreak with a wrap-up session, where we reviewed everything we’d done, agreed how to finish or stop things which were in progress, and captured all the ideas worth holding onto.
And that was it - no more structure required. People were free to self-organise in whatever way made sense to get things done.
What value it created
In total there were 70 ideas pitched, of which 22 were delivered and 36 are things we agreed to take forward in the future. Not bad for a team of around 60 people.
Problems we’d been putting up with for months (in some cases years) got fixed; big and bold ideas were explored including one which will have a huge impact on how we improve our content and navigation; we learned from a failed experiment about improving site search; and we made a whole heap of immediate, tactical changes which will speed up our delivery and reduce human error in future - like cutting our release process (a task we perform about 10 times per day) down from 30 steps to just 5.
The work was varied - ranging from an extremely important and useful disaster simulation game day to test our resilience, through to quick and fun projects like www.gov.uk/random which returns a random page to help people discover content on the site.
People paired with people they'd barely spoken to before,some spent time shadowing people from other disciplines to learn how they work, and about 40 of us took part in a workshop on how we can improve our culture.
And, most importantly of all, the team regained its energy.
What we learned from the process
We also learned lots about how to do this kind of thing better in future.
Several team members felt that the projects were too developer-centric. That’s probably a consequence of the amount of tech debt we’d built up, but it’s something to guard against next time.
Our content team weren’t able to be involved (it was bad timing for them) and their skills and knowledge were sorely missed. We’d like future firebreaks to be more inclusive - involving our users across government who were invited, but whom we could have done more to include.
People suggested it would be better to focus on a theme in future firebreaks, and to do all the thinking up front and have product management vet the ideas. Expectations and measures of success could have been clearer.
Many of the projects ended up being too big (don’t they always?), with lots of unfinished work in at the end of the month. A focus on prototyping rather than building solutions for some of our bigger problems might help deliver more value in the time available.
We didn’t blog enough about the projects (watch this space on that, though).
And finally, in future we will run firebreaks for shorter periods - likely to be 2 weeks, about every 6 months. We think that 2 weeks is long enough to get some good stuff done and short enough to allow everyone to pause all but the most essential day-to-day work and get involved.
A note on the word “firebreak”
GDS delivery manager Jamie Arnold coined the term “firebreak” around this time last year, and it stuck. Some of our teams have run similar things before, but this is the first time we’ve done anything at this scale. A quick Google search confirms it’s not a widely used term, the only other use of it in the context of agile development being this blog post from 2010 which is well worth a read if you’re hungry for more. Maybe the name will catch on?
If work like this appeals to you, take a look at Working for GDS – we’re usually in search of talented people to come and join the team.