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

http://hakanforss.files.wordpress.com/2014/03/are-you-too-busy-to-improve2.png

Debugging: Root cause analysisOana Feidi10.05.2014

Please fill in your evaluation form