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.
It was just as productive a time as usual, if not more so. Our roadmap update posts from 16 January and 4 February list everything we got done if you want the full details.
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.
13 comments
Comment by Alan Cooke posted on
'If it’s important, it really will come up again'
Have I misinterpreted this as customers need to keep repeating their requests in the hope they may get actioned at some point?
Comment by Neil Williams posted on
Yes, you misinterpreted / I wasn't clear. Lots of the things on a backlog arise internally, and we're pretty diligent about tracking requests from colleagues around government (not just in backlogs - we'll blog soon about the improvement plans we're developing, which will be a better way of capturing the improvements needed per product area).
Comment by Howard Gannaway posted on
I first experienced this "delete the backlog" technique in 1979 while working for a large insurance company (everything on paper then!) New business applications were taking ages to get turned round at head office and those of us in the local sales offices were getting very frustrated. Then, quite suddenly, everything changed. New business applications were being turned around in 24 hours. It was only many years later that I coincidentally bumped into the management consultant who had been brought in to stop head office drowning in paper. He told me that the first step was to ensure that new business could indeed be turned round in 24 hours and then to take all the paper off everybody's desks and stack it in large piles round the walls of the rooms! From then on people were only to deal with new business applications.
Over the subsequent days and weeks people chased up their communications but were really important but much of the paperwork was never touched again. The key point about this technique seems to be that it should only be applied when there is a genuine service improvement or a genuine understanding that new improved service levels can be met after the break.
Comment by Caroline Hills posted on
I'm curious to know what the reaction was from stakeholders to the team being unavailable for planned work other than essential stuff during that period, and did you make them aware of this well in advance?
Comment by Neil Williams posted on
Hi Caroline. Good question. Essential stuff did include some planned work, but the product management team kept that to a minimum. Another way of saying the same thing is that we *planned* to work on addressing technical debt, re-energising our team and making process improvements - prioritising those things above new feature development.
We did get agreement from stakeholders, yes, via our Steering Group which is made up of representatives from government departments and agencies. They were remarkably supportive. They had all individually been through an intensely busy time with their own transitions to GOV.UK, so it was easy for them to imagine how that must have been for the team in GOV.UK which has worked on *every* transition. And they understood that development would just slow down if we didn't reset and reduce some of the debt. (The debt metaphor is very apt: if you saddle yourself with too much of it you end up spending all your budget just paying the interest).
Comment by Geoff Craig posted on
Hi,
I work in another government organistaion and a few of us have formed a group looking at what motivates staff and how we can generate a more productive/creative work environment. Your 'firebreak' is perfectly aligned to our current thinking and could be something we would like to trial and duplicate, maybe on a smaller scale. Is there somebody we could talk to, to learn more about your experience?
Comment by Neil Williams posted on
Yes you can speak to me or Lindsey Keighly. I will email you.
Comment by Amit posted on
How exactly did you refine or change your processes, and make sure people follow any new/improved processes that came out of this months' firebreak?
Can you email me about that?
Comment by Neil Williams posted on
It varies. In some cases, for example process improvements to speed up our software deployments, we refined the technical tools and improved the documentation/checklists which people were already using. So we didn't need to do anything additional to make it stick.
Then there are things like the actions which were identified in a 3 hour workshop on our internal culture. That's created a whole separate worklist which we are now tracking on a kanban board and will progress over time.
And then there are also examples of less well-defined process change following the firebreak, for example pairing more, talking more, doing more frequent show and tell demos.
Hope that's of some help.
Comment by Amit posted on
Thanks for the note.
I don't fully understand the first point about updating documentation/checklists - which are just static things that people look at. How do you track what has actually been followed? How do you know if anyone is actually reading the documentation or checklists? How do you "make it stick" exactly?
If new people enter the team, how long do they take to on-board? Do they have to read a large pile of documentation in order to see how things are done?
Comment by Neil Williams posted on
With that specific example the steps are built into our software, largely. You can't deploy without pressing the buttons, so there's no problem of adoption. I notice you're from a vendor of process software, which looks interesting but not for us thank you.
Comment by Amit posted on
Thanks, but we are not pitching you about anything - and nor would we support you in using our tool - which is aimed at specific problems.
This was to understand how things work at your end.
Comment by Dan posted on
This is really interesting, thanks for sharing! We've just started to work like this, only the idea is to 'Firebreak' 100% of the time... Which will be interesting! We should probably blog about our journey.
I was wondering what product managers did during your month? I read in an earlier comment they did some work with keeping commitments as low as possible, but apart from that what else did they get up to?
As a product manager myself in finding myself wondering exactly that!