Debugging: Root cause analysis
Oana Feidi10.05.2014
Motivation
Symptoms of the problem OBVIOUS
Underlying causes NOT OBVIOUS
CAR DOES NOT START
Cultural backgroundPower distance index, driven by respect to authority and attitude towards hierarchy
Malcolm Gladwell - “Outliers: The Story of Success”
The problem: Financial audit failed due to inconsistencies in financial
report data.
Initial root cause:Incorrect rounding of “totalPayment”
parameter.
SYMPTOM
Why didn’t the validation team
detect this?
TC defined for this scenario?
TC defined according to
specification?
Results of the test run?
How was the review
performed?
Why was this not detected at code review?
Review content?
Reviewer’s experience?
Result of the module test
run?
How was the change
handled?
Motivation
http://www.roystonrobertson.co.uk/trade.htm
Simplest 5 Why analysis
http://raisedbymydaughter.blogspot.ro/2013/01/on-kids-asking-why-and-cruel.html
5 Why approach
• Why?• Because1 • Why?
• Because2 • Why?• Because3
• Why?• Because4 • Why?
• Because5
Why did we have the problem?Why did the problem go to the customer?
5 Why : Unhappy customer
1. Why is our client unhappy?
Because we didn't deliver our services when we said we would.
http://www.mindtools.com/pages/article/newTMC_5W.htm
5 Why : Unhappy customer
2. Why were we unable to meet the agreed-upon timeline or schedule for delivery?
Because the job took much longer than we thought it would.
5 Why : Unhappy customer
3. Why did it take so much longer?
Because we underestimated the complexity of the job.
5 Why : Unhappy customer
4. Why did we underestimate the complexity of the job?
Because we made a quick estimate of the time needed to complete it, and didn't list the individual stages needed to complete the project.
Review planning
Template with most common
activities
5 Why : Unhappy customer
5. Why didn't we do this?
Because we were running behind on other projects.
Synch projects prioritization
CODECAMP is a successful event
• 12 editions; consistently increase number of participants
WHY?
5 WHY
ROOT CAUSE ANALYSIS
LESSONS LEARNED
Release retrospective
• Provide a structure for output upfront
Release retrospective Meeting execution
• Look for solutions!!!!! & K.I.S.S• Always ask:
what can be done differently?• 1 responsible / clear deadlines• Agree within the team
Release retrospective Next meeting
• Check effectiveness of the previous actions• Did we derive the correct actions?• Why we keep making the same mistakes?
• Indentify if new situations appeared & derive new actions
http://www.business2community.com/product-management/9-lessons-learned-in-project-management-0292183
http://www.snrky.com/2013_08_01_archive.html
Lessons learned – End of projectStep 1
• organize a lessons learned workshop @ end of project
• provide a structure for output upfront ~ 2 weeks• POSITIVE, as well as NEGATIVE• technical, as well project management related• prepare SPECIFIC examples, no general things
Lessons learned – End of projectStep 2
• do the workshop• focus on SOLUTIONS that prove to work & useful for other projects – K.I.S.S.
• no personal attacks• always ask:
what can we do differently in the next project?
• output result : situation + SOLUTION
Lessons learned – End of projectStep 3
• agree on the lessons to be transferred in the database (generic, general)
• clear key words
Lessons learned - Start of project
Select the lessons learned that are applicable for your project
Define specific actions/activities to keep under control the hints from the lessons learned
Regular check of the effectiveness of the actions/activities defined at previous step• Refine/update the actions/activities
based on the effectiveness result• Update database with your own best practices/results
5 WHY
ROOT CAUSE ANALYSIS
LESSONS LEARNED
Debugging: Root cause analysisOana Feidi10.05.2014
Please fill in your evaluation form