Better Software - June 2008 - (Page 38)

if The resulTs of an rca are used To rePrimand or Punish a Person who has made an honesT misTake, The Process will quickly cease To be effecTive. short term. Their thinking seems to be “If we can just get the developers to make fewer errors, we can improve product quality.” While this is true over the long run, this approach ignores the time lag between understanding the root cause, identifying where the cause actually occurred, and then applying prevention to that activity. In the case of requirements errors, the next opportunity to apply the prevention is in the requirements gathering activity of the next version or even the next product. This means that actual improvement seen by users will be at least a full product release cycle away. A second problem is failure to take action after the analysis has identified the root cause. The process seems to morph from “Find the root cause and prevent its recurrence” to “Hold the RCA meeting to meet a goal” and no further time, people, or money are spent in actually preventing the problem from recurring. Eventually this leads to “Why are we wasting time in this meeting? No one ever does anything with the findings,” and RCA is abandoned as ineffective. A third and even deadlier problem is punishing the person who made the error. If the results of an RCA are used to reprimand or punish a person who has made an honest mistake, the process will quickly cease to be effective. Making the same error over and over after identifying the problem and applying corrective action is another story. The key is to use the results of RCAs to improve a person’s or team’s capability. I would advise erring on the side of “forgiving and learning” rather than “reprimanding and punishing.” to be avoided the next time. For example, a finding of a retrospective might be “Too many defects found in module xyz in system test delayed delivery.” At this point, an RCA of the cause of those defects would be performed. Another finding might be “Initial estimates were 50 percent too optimistic.” An RCA of the estimating process could be conducted. In many cases, the output of retrospectives or lessons learned is identification of the “primary effect” (a term to be explained later) rather than the root cause. The rca Process rca versus reTrosPecTives While an important process improvement technique, retrospectives do not typically focus on root causes. They are a good source of information for RCA but often only identify things that worked well and should be done again or things The following three methods have been found useful for conducting RCAs for software failures: • Apollo method • Fishbone or Ishikawa diagrams • 5 Why I prefer the Apollo method for analyzing software failures, as it has enough Figure 1: Apollo method cause-and-effect chart 38 BETTER SOFTWARE JUNE 2008 www.StickyMinds.com http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.