All development organizations have a number of recurring events that waste the time of their teams. When reviewing the subject of Defect Lifecycle Management two of the most important undesired incidents are :
(1) Rejected Defects – Defects that are reported by the QA and rejected by the product or development teams.
(2) Reopened Defects – Defects that are fixed or rejected by the development and are reopened by the QA.
These incidents continually waste the time required to detect, report, review, analyze, assign, and/or fix an important number of defects; and they usually are the result of human error and/or lack of communication (and understanding) between people in different teams. Even if at the first glance the number of defects may appear small, when reviewed closely they add up to days and weeks of wasted time per project.
A couple of years back I worked at a company that implemented an effective way to fight this unnecessary waste. As part of our monthly QA reports with all sorts of project and defect data we started providing the accumulated statistics for the Percentage of Rejected and Reopened Defects per project together with a threshold and traffic light dashboard for each. Deviation of up to 10% brought a yellow-light indicator and after that the projects turned to red on these specific measurements.
The reports were sent each week to each Development & QA Manager and the dashboards were presented once a month to the VP R&D during the periodic Directors’ Meeting where they quickly became a topic of choice, especially as our organization was looking for ways to improve the efficiency of our internal processes.
Each manager was responsible for his own area and was required to explain any major deviations from the set threshold. At the beginning only one in seven teams was bellow the threshold and two more where close to it; more importantly many managers thought the measurement unfair and the threshold impossible to maintain over time.
Then, with the constant pounding of Management and after some months of analyzing the chain of events around defect reporting, more teams started showing green-light indicators. We continued producing and studying these numbers until most teams had improved their metrics and defect management processes considerably around this area.
The above exercise showed me 2 things:
(1) Teams can work more effectively by making sure they communicate better, creating less unnecessary garbage and friction in the process.
(2) There are many hard things that can be achieved once the correct information is placed in the spotlight and enough focus is put in the right places.
Organizations should implement the good habit of keeping track of statistics for these kind of unwanted behaviours. They should keep thresholds for the maximum number of trash their systems produces and in cases where these thresholds are exceeded they should understand the root cause and fix it.
