Our team here is very much in agreement with the Shape Up stance on the matter of 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.
Ultimately software engineering is about adding-value. Sometimes fixing a bug is the most valuable thing you could be doing. Often times it’s not at all. The resources dedicated to a bug fix should be weighed against all the other value-adding activities you could be doing.
You’ve already shortlisted your best value-adding raw ideas, you’ve shaped them up, brought them to the betting table, and the team voted to bring them to the next cycle. Now you’re going to pre-empt all that evaluating, prioritizing, and planning because someone noticed your software isn’t perfect?
Frequently it makes little sense to interrupt the team’s momentum toward their current tasks just because someone found a bug. Surely whatever the team is working on must be something deemed to add a lot of value otherwise it wouldn’t have gotten past the betting table. A new feature might add value to a great number of customers while the bug might only affect a handful of users and in only a small number of circumstances. These things really need to be considered in the context of their impact and all the other value-added things you could be working on. Otherwise, you might win the Battle of the Bugs but lose the war for profits and market share and cede your competition an opportunity to win the hearts and minds of your customers. Your “bug-free” software can’t keep up with the velocity in which my team is able to add game-changing features.
The embarrassment you speak of is something we explicitly embrace. I’d rather apologize to a minority of inconvenienced customers than lose valuable momentum on a high-impact feature that’s going to wow masses of users, significantly improve operational efficiency, accelerate our growth, and have a big positive impact on our bottom-line.
That being said, we do care about bugs and we have processes to deal with them, we just feel their priority should be determined by a rational evaluation that puts them in context with other value-adding activities.
Think in terms of grading bugs along a “Bug Bell-Curve.” A small percentage of bugs demand immediate attention, a small percentage can be ignored for years, and most fall somewhere in-between.