Recently I have been discussing with various people about bug fixing and getting high quality software. as part of that I happened to comment a blog entry about incentive driven bug fixing activity called "Bug Week" and thought it to be bad practice due to Deming's points about incentives and the personal experience I have for developing software and managing the development of software. The discussion went even further.. I might address the "objective of zero defects" later as it is a whole different topic addressed by lots of people.
Nate however asked very common question that I have heard from various agile teams:
"How to allocate time for bug fixes in sprints while continuing to add new capabilities to the product."
I have multiple non-incentive driven solutions that I have tried with various teams:
1. The Huitale Way - Drop sprints, Stop-and-Fix
As you might know, we in Huitale practice stop-and-fix as our bug fixing practice.
2. Allocate X% of your velocity for bug fixing and other maintenance tasks
If you need to support an existing version of the product while you are sprinting it is a good idea to allocate time for support/unplanned work/maintenance/bug fixing in all your sprints.
3. Bugs as backlog items
Fixing bug must be valuable. Why not to estimate that business value and prioritize the bugs as items in your product backlog? Some bugs might even not be worth of fixing.
4. Have limit for bugs
Some teams have set a limit for bugs. They try to keep number of known issues less than that limit. When the limit is about to be exceeded by a new bug they will start fixing some bug immediately to make room for the new bug.
5. If you are running Kanban, have a swimlane/SLA/Urgent slot for urgent work
Community members have already described urgent slot, swimlanes, and SLAs so I won't do it here.
In the end of the day it is about everyone taking responsibility and being responsible about the product. If you do not have that, no incentive, set objective or practice will help.