Common Mistakes #5 - Focus on Working Software, Not Tracking Bugs

At a recent industry Agile conference, we shocked a whole room full of people by announcing that 10X does not use a bug tracking system during development and testing.  We were immediately barraged with questions:

• You can’t write perfect software!
• How do you not keep track of defects?
• How do the software testers communicate issues found to development?
• How do you prioritize bug fixes if you don’t have a list?
• What about production problems?
• What about tracking severity 3 or 4 defects?
• How do you measure code quality?
• How do you track the effectiveness of QA?
• Don’t you need metrics to report to management?

Our response:  Tracking defects makes you less efficient. Don’t focus on tracking them, focus on fixing them!

How many long painful meetings have you attended where lists of defects are discussed, prioritized, and subsequently never fixed? The overhead required to discuss, document and manage the defect often exceeds the value derived from those efforts and distracts from the work at hand. Just entering defects can sometimes take more time than fixing them.

Often teams keep metrics on the number of test cases run and defects found and fixed.  Management then uses these metrics to determine productivity. This not only creates overhead but can incent bad behavior. In the past, we have seen testers write test cases of low quality or run test cases they knew would fail so that their metrics would look good.   How ridiculous!  Focus on what matters! 

In the end, working software is the goal, not how many bugs were found along the way.

During a project, avoid defects by developing and testing feature functionality within the same team and within the same few sprints. We don’t split the development and test organizations. They work together as one team. When a defect is discovered, the team discusses it and decides whether it should be addressed during the current sprint. If so,  it gets added to the current storyboard.  If the defect is not deemed critical enough to fix immediately, the team may add it to the backlog or simply decide that it will not be fixed.   The point is to avoid the extra effort involved in adding defects to a bug tracking system and to fix them as quickly as possible so that you don’t accumulate a lot of technical debt and spend time managing that debt.

Production issues can easily be worked into the current sprint. If there is no team currently in place actively doing development for that product, the bug can be worked into a backlog or storyboard managed between the supporting development and operations groups. New tests can be added to the test automation suite and can be used to validate that the fix hasn’t broken existing functionality. Granted not all bugs are that easy to find or fix in production and customers may require tracking.  Keep it simple. Pick simple tools to help keep track that don't add too much overhead. Do not allow the list to grow! If your bug lists become large then, perhaps, there is a different issue that needs to be addressed.