<aside> ℹ️ Bugs in software development do not automatically take precedence over other tasks unless they cause severe issues. Most bugs can wait for six weeks or longer for fixing, and some may not need fixing at all. Three strategies for handling bugs include using the cool-down period between cycles for bug-fixing, bringing significant bugs to the betting table to compete for resources, and scheduling a dedicated "bug smash" cycle, typically around the holidays.

</aside>

If the teams aren’t interrupted in the six week cycle, how do we handle bugs that come up?

First we should step back and question our assumptions about bugs.

There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare. The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.

That said, nobody likes bugs. We still want ways to deal with them. Three strategies have worked for us.

Use cool-down. Ask any programmer if there are things they wish they could go back and fix and they’ll have a list to show you. The cool-down period between cycles gives them time to do exactly that. Six weeks is not long to wait for the majority of bugs, and two weeks every six weeks actually adds up to a lot of time for fixing them.

Bring it to the betting table. If a bug is too big to fix during cool-down, it can compete for resources at the betting table. Suppose a back-end process is slowing the app down and a programmer wants to change it from a synchronous step to an asynchronous job. The programmer can make the case for fixing it and shape the solution in a pitch. Then instead of interrupting other work, the people at the betting table can make a deliberate decision. Time should always be used strategically. There’s a huge difference between delaying other work to fix a bug versus deciding up front that the bug is worth the time to fix.

Schedule a bug smash. Once a year—usually around the holidays—we’ll dedicate a whole cycle to fixing bugs. We call it a “bug smash.” The holidays are a good time for this because it’s hard to get a normal project done when people are traveling or taking time off. The team can self-organize to pick off the most important bugs and solve long-standing issues in the front-end or back-end.