Agile Zone is brought to you in partnership with:

Michael became a Certified Scrum Master (CSM) in 2004 and is huge advocate of better (XP) engineering practices since discovering unit testing in 2001. Michael has a B.A.Sc. from University of Toronto in Engineering Science and a M.Sc. from U.B.C. in Computer Science. He has presented at Agile Tour Toronto and the XPToronto/Agile User group on Scrum and XP. His is also an active member of the Agile community and co-organizer of Agile Tour Toronto. Michael lives and works in Toronto, Canada, as an independent Agile and Lean coach, consultant and trainer. Michael is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

Go Faster with Root Cause Analysis

06.29.2010
| 5096 views |
  • submit to reddit

One of the workshops I run is to help team members understand root cause analysis. I use it with operations teams as well as product development teams. My workshop goal is to have people leave with a basic understanding and some practice.

I created the diagram below to situate this workshop in a larger context of Kaizen (Continuous improvement).

One starting point is with a team using a Scrum board or Kanban to create BIG visible information. This supports teams in identifying problems or waste to stop the production line and investigate the problem using root cause analysis tools. I introduce two tools and have the participants practice with each:


Both of these improve quality to help teams go fast. 5S (sort, straighten, shine, standardize, sustain) is also totally applicable for software – it’s called clean code: coding standard, refactoring, etc.

Finally, the foundations for Kaizen and root cause analysis are:

  • NO BLAME. Most problems are related to the system, not individuals.
  • Team work and trust. If 100 people each help find 1% improvement, this will be sustainable.
  • Genchi Genbustsu – Go and See.  When you work on a problem, go to the source and get the facts for yourself. Root cause is about investigation and problem solving – see and think for yourself.


If you want to learn more, check out Implementing Lean Software Development: From Concept to Cash or Toyota Production System: Beyond Large-Scale Production.


Workshop Slides

Here is a slide deck I have used in training. It’s from last year, and would benefit from a refresh to cut down on the text – still very usable. As usual, you are welcome to use this as well as the diagram under Creative Commons license.

 

 

References
Published at DZone with permission of Michael Sahota, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Nguyen Son replied on Tue, 2010/06/29 - 8:57am

Michael, I do not practice agile in my projects, however I find root-cause analysis an extremely useful tools in understanding project problems, and also in identifying and eliminating risks to the projects. The main difficulty in root-cause analysis, in my opinion, is that when problems are messing up your project, you have no time analysing root causes. However, when problems are over, you become relaxed and forget to do the analysis. I have an article regarding root-cause analysis too in my blog, enjoy reading. http://pmreviews.org/2010/06/21/look-back-not-just-forward/

Michael Sahota replied on Mon, 2010/07/05 - 8:26pm in response to: Nguyen Son

Nguyen, I agree - root cause analysis is completely independent of what software process you are using. What I have seen some teams do is to define "done" for a production issue to include root cause analysis. There has to be a commitment to spend time on quality and improving things otherwise it will get skipped as you mentioned. Thanks for sharing your article.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.