Debugging - Root cause analysis

1. Debugging: Root cause analysis
Oana Feidi
10.05.2014

3. Motivation
Symptoms of the problem
OBVIOUS
Underlying causes
NOT OBVIOUS

4. CAR DOES NOT START

5. Cultural background
Power distance index, driven by respect to authority and attitude towards hierarchy
Malcolm Gladwell - “Outliers: The Story of Success”

6. The problem:
Financial audit failed due to
inconsistencies in financial
report data.
Initial root cause:
Incorrect rounding of “totalPayment”
parameter.
SYMPTOM

7. 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?

8. Why was
this not
detected at
code
review?
Review
content?
Reviewer’s
experience?
Result of the
module test
run?
How was the
change
handled?

9. Motivation
http://www.roystonrobertson.co.uk/trade.htm

10. Simplest 5 Why analysis
http://raisedbymydaughter.blogspot.ro/2013/01/on-kids-asking-why-and-cruel.html

11. 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?

12. 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

13. 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.

14. 5 Why : Unhappy customer
3. Why did it take so much longer?
Because we underestimated the complexity of
the job.

15. 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

16. 5 Why : Unhappy customer
5. Why didn't we do this?
Because we were running behind on other
projects.
Synch projects
prioritization

17. CODECAMP is a successful event
• 12 editions; consistently increase number of participants
WHY?

18. 5 WHY
ROOT CAUSE ANALYSIS
LESSONS LEARNED

20. Release retrospective
• Provide a structure for output upfront

21. 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

22. 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

24. http://www.business2community.com/product-management/9-lessons-learned-in-project-management-0292183

25. http://www.snrky.com/2013_08_01_archive.html

26. Lessons learned – End of project
Step 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

27. Lessons learned – End of project
Step 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

28. Lessons learned – End of project
Step 3
• agree on the lessons to be transferred in the database
(generic, general)
• clear key words

29. 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

30. 5 WHY
ROOT CAUSE ANALYSIS
LESSONS LEARNED

33. Debugging: Root cause analysis
Oana Feidi
10.05.2014
Please fill in your evaluation form