January 21, 2019

Changing Defect Management to include Root Cause

  —Root cause analysis for defects is critical for improving your process.

I’m in the process of changing defect management in my team. We use our retrospective to review defect and cost overruns during the sprint.

The change I’m making incorporates two ideas:

  1. every defect is a lifecycle issue, and
  2. start with the code change that prompted the defect.

The first idea ensures the retrospective remains a safe place to acknowledge errors. This is important because the errors that prompted the defect could be the result of an error made by someone at the retrospective. For example, a coding error that escaped code review.

The second idea ensures we focus on root cause and not the defect correction. This is important because the defect is a symptom. First, focusing on the correction would repeat the code review. Second, this sets up the context so that the focus is on what was being attempted when the defect was introduced.

I focus on the code because that’s closer to where the error manifests. Defects manifest as a behavioural or functional issue because something isn’t meeting the expectation of “working”. Since we have a patch for the defect we have a notion of what expected behaviour is. What we don’t know is where the problem entered the lifecycle.

I could focus on the test but it seems obvious we lack a test case otherwise the defect would have been corrected earlier. Clearly, a lifecycle issue that manifests in requirements won’t have a test case…

Since the code is the focus I use the commit history as the starting point.

R3 <- defect fix applied to great new feature
R2 <- another great new feature
R1 <- great new feature

The patch applied in R3 might update changes in R2, R1 or both.

What motivated R3 is interesting. What motivated R3 is in R1 or R2 or both.

That is R3 might:

  • fix something in R1,
  • fix something in R2 that negatively impacted R1, or
  • fix something affecting both R1 and R2.

The problem gets complicated when there are many revisions affected by the defect fix. Such situations will bring in multiple people and perspectives. And hopefully ways to mitigate recurrence.

comments powered by Disqus