Our team are currently ‘on firebreak’. What on earth is that?
Like Spring Break, but more toasty?
A firebreak is a week or so of self-directed work, that isn’t part of the team’s immediate goals. On GOV.UK Pay we usually plan our day-to-day work to a quarterly schedule, so we aim to have a firebreak once every three months.
The point of a firebreak is to give everyone time and space to do something different: spike out something new, test a hypothesis, do some housekeeping or work on a project that there wouldn’t otherwise be time for. The only caveat is that you have to be prepared to drop the work at the end of the week if it isn’t finished.
Normal agile ceremonies like standup, planning, retro etc are skipped - it’s up to you to decide how to work, but collaboration is encouraged, especially if it’s with someone you don’t normally work with that closely. To facilitate this, at the beginning of the week there’s a ‘pitching session’ where you can recruit people (say, a designer or developer) to help you work on your idea.
Our support rota changes too - rather than some poor soul spending their entire firebreak week on support, we rotate every day so everyone gets a go.
At the end of the week, you share your project with the rest of the team. It doesn’t matter if it isn’t finished, or even if it is a complete failure - in fact those failures often make the best show-and-tell spots (and it might stop someone making the same mistake later).
For various reasons we didn’t have a firebreak last quarter, so we’re getting a 2-week firebreak this time round, hurray!
What have you been doing, Kat?
Historically I have been Bad At Firebreaks™, sneakily finishing off pieces of work from the quarter, covering support, or getting a head start on planning the next one. Or I used the time to take annual leave, as I knew I wouldn’t ‘fall behind’ that week (clearly nonsense). Often I simply couldn’t think of a cool idea 😿.
This time I’m pleased to say I’ve been spending time doing my two favourite things:
- deleting stuff
- updating the team manual to say I’ve deleted stuff
Specifically, I’ve archived 20 of Pay’s Github repositories that were no longer in use. These were causing extra overhead the other week, when I was trying to check whether our repos were affected by a recent vulnerability (thankfully none of them were).
Kat’s top repo archiving tips:
- add an archive notice to the README saying WHEN you archived it
- close any issues or PRs
- turn off Github Actions
- delete any secrets
- ensure all the settings follow your team’s policy
- update your documentation so it’s clear you’re no longer using the repo
Of course I am also spending some valuable firebreak time writing this blog post.
A break between fires
In the real world, a firebreak is usually a stretch of gravel or earth that stops fires from reaching the other side. For us, this metaphor doesn’t quite stand up to closer inspection: after firebreak is over, all our normal work is still there and carries on.
However the idea is that after a week’s break doing something else, we’ll come back refreshed and ready to tackle whatever’s coming. We might even have some new ideas on how to go about it.
I think it’s a shame that some leadership folks aren’t convinced that a firebreak is a good use of their team’s time. Making some space for your teams to innovate and experiment can yield some very cool results, and can even help stop your team burning out.