Daily Clean Code
... bugs turn into features at midnight ...
I once worked on a very large software project. Over time, our bug list grew larger and larger, until everyone realized that something had to be done. A team was dispatched to clean up the bug list; to either fix the bugs or remove them from the list. A couple of months later, management announced with great fanfare that the bug list had been reduced from around a thousand bugs to some six hundred, thus reducing the number of bugs from astronomical to merely unmanageable.
As a team develops the product, bugs are invariably detected. The usual tendency is to write bug reports and put them on a bug list, where they will be fixed at the appropriate time. But this leads to several problems which ultimately cause the velocity of the team to bog down.
Here we discuss bugs that arise within the sprint. Preexisting bugs should be prioritized by the Product Owner and managed in the Product Backlog. Bugs appearing from outside the sprint such as customer emergencies should be handled by the Illegitimus non Interruptus pattern.
✥ ✥ ✥
It is natural to want to keep a list of bugs. There are several forces that encourage this.
However, keeping a bug list causes numerous problems, such as the following:
In short, deferring the fixing of bugs until later is borrowing against your future velocity.
Fix all bugs in less than a day. Aim to have a completely clean base of code at the end of every day.
This is simply practicing good housekeeping. If you find a cockroach in your house, you kill it right away.
In order to make this work, avoid the temptation to keep a bug list. You already have a list of work to do, the Sprint Backlog. As bugs are identified, they are either fixed immediately or go on the Sprint Backlog to be fixed later in the day or the very next day. This allows developers to complete their current task without interruption, if necessary. Naturally, if it's a bug you find, fix it now, while it is fresh in your mind.
Note that putting the bug on the Sprint Backlog does cause the bug to be handled twice, so the ideal is to handle the bug immediately. But there is a tradeoff between handling it immediately and continuing current work without interruption.
If a bug cannot be fixed within one day, then that may indicate a more serious problem with the design of the product. After all, no bug should take very long to fix. Causes of such bugs should be discussed in sprint retrospectives.
It is still usually necessary to have a bug reporting mechanism for customers to write up bugs. If you have one, use it only as a holder for bug reports that have not been examined yet. Once you examine a bug report, handle it immediately as described above. Resist the urge to read it and leave it in the bug reporting system to be handled later.
Note that while the focus of this pattern is on fixing bugs, one should also treat refactoring the same way. After all, refactoring is a way of cleaning up the code, and the at the end of the day, the code should be as clean as possible. Like bugs, deferred refactorings are technical debt.
How does this help velocity?
If a team already maintains a bug list, then moving to this pattern will be painful and require a lot of work. However, fixing bugs immediately will radically reduce time needed for testing. Since testing is usually the bottleneck, deployment will go faster. For these reasons, the change over to immediate fixing of bugs discovered in a sprint is recommended. A plan for remediation of technical debt introduced through old bugs should be developed and implemented.
This is a radical break from the traditional way of thinking. Teams that maintain a bug list must not only eliminate their existing bug list, but must change their way of thinking. Strong commitment from the team is needed, along with constant reminders, especially from the Scrum Master (see DoneMaster and Sheepdog).
The source of data on this is a paper on Scrum and CMMI where a CMMI Level 5 company drove the doubling of productivity on every time using control charts that manages bug fixes to less than a day (ideally averaging two hours). C. Jakobsen and J. Sutherland, "Scrum and CMMI – Going from Good to Great: are you ready-ready to be done-done?," in Agile 2009, Chicago, 2009.
This pattern may replace or augment Whack the Mole.