A few days ago I posted a presentation entitled Counting to Zero, A Software Wellness Program for Iterative Development Teams. We are implementing this program in my workplace, and I have had questions worthy of open discussion.
In order for these questions to have context, I recommend you watch the presentation.
Question #1
Shouldn’t teams be incented to find and fix defects?
No. Teams should be incented to avoid defects, not find, track, and fix them. There is more value in avoiding defects than finding them and a Software Wellness Program rewards defect avoidance over defect detection. Better than finding and tracking a defect is not releasing a defect in the first place.
For example, if a developer and tester are sitting next to each other and Tester Bill says, “Hey, Developer Joe, I found an issue here,” it makes a lot of sense that Developer Joe fix the issue immediately and Tester bill confirms the fix. This can happen within minutes in a highly collaborative and functional team.
In this scenario, there is no need to enter the defect into a tracking system in the first place. This means the lights never come on and we never need to worry about them.
Having software be out of tolerance, and therefore having the team light on red, is not a positive thing. Let’s not cover up that fact.
Question #2
Let’s assume the team gets a software epic to zero defects. Is it reasonable stop feature development and fix a bug under red light conditions just for 1 defect?
Yes. The reason is related to question #1. Remember that the defects we are tracking are not coming from the real-time feedback loop occurring within the teams. Defects that enter into the triage system are a BIG DEAL and should be treated as such. These are issues that are important to the business, not just to developers.
Remember too that the team light can only go red as often as the triage team meets. Frequency of triage dictates in large part the accuracy of the real time defect count.
Lastly, it is much easier to keep a clean codebase clean. This means the longer you wait to fix a defect, the harder it will be to actually fix it. Allowing your code to grow around a defect increases the cost of fixing it. This is directly related and proportional to the complexity of the codebase.