Optimizing Bugs Fix Policy
I am sure you are familiar with the following scenario: a user is reporting to your Support team tha t something is not working for him as expected. Your Support team investigates the issue and agrees that there is a bug in the system. They open a JIRA bug to the R&D department with all the information they have collected, as expected from them. But then… a furious argument begins on the ticket. Support is saying that they think R&D should solve this bug within a week. The Customer Success Manager is saying this is a critical customer just before renewal. Therefore we need to make all of the effort to solve it within 48 hours, but R&D doesn’t see this as an urgent matter and thinks the bug should be solved within 30 days. Who is right?!
On the two last engineering organizations, I led as a VP, when I joined, we faced that kind of dilemma daily. When we analyzed it, we figured out that there are just too many open bugs all across. In this reality while the support is trying to call what is the right SLA, the developers are overwhelmed with the number of open bugs without a clear idea on how to prioritize between them, therefor calling loose deadlines, and the client-facing teams are also trying to figure out how to move in this mess and lack of SLA communication, while not counting on the R&D to solve soon enough (or even to solve at all), therefore expediting those bugs, more than needed. The solution, was a combination of “Zero Bugs Policy”, formulating a “fix policy”, and enhancing communication interfaces. This was achieved in some easy-to-implement / straightforward steps.
