The document discusses how British Petroleum (BP) improved its oil exploration success rate by enforcing a policy of zero dry wells, resulting in a significant increase in successful drilling. It draws a parallel to scrum teams, suggesting that they challenge the status quo regarding software defects and aim for zero defects by implementing Test Requirement Driven Development (TREDD). The approach emphasizes collaboration among team members, reduced product defects, cost savings, and a focus on quality from the development stage.

1. Help Your Scrum Team Strike OIL!

2. FINDING OIL IS HARD
• On Average Oil Companies Have *
– 1 chance in 8 for finding oil
* All notes pertaining to British Petroleum and oil exploration originate from
“SWITCH: How to Change Things When Change is Hard”, by Chip and Dan Heath

3. FINDING OIL IS HARD
• On Average Oil Companies Have *
– 1 chance in 8 for finding oil
• For British Petroleum It Was
– 1 chance in 5
– Better but still a poor rate of return.
* All notes pertaining to British Petroleum and oil exploration originate from
“SWITCH: How to Change Things When Change is Hard”, by Chip and Dan Heath

4. THEN BP MADE A CHANGE
• The Change Was To Insist That Oil Exploration
Had To Result In NO Dry Wells
• In Other Words They Had To Be REALLY Sure
That They Will Find Oil.

5. SO WHAT HAPPENED?
• BP Oil Exploration Improved Dramatically!
– 2 out of every 3 wells drilled was a strike
– That is equivalent to a baseball player improving
their batter average from .200 to hitting .667
UNHEARD OF!!!!

6. HOW WAS THIS ACHIEVED?
• BP Rejected The Industry Status Quo
– That oil exploration meant that some wells would
hit oil, others would not (be dry), you just had to
drill enough wells to find one
• They Worked Smarter
– Used prior exploration information
– Applied geologists knowledge and technology
more effectively

7. RESULT
• With Fewer Areas In The World Left To Explore
For Oil
– BP found more untapped oil reserves
– Increased their profit by reducing their costs
– Reduced environmental impact with fewer
exploratory wells

8. WHAT DOES THIS MEAN FOR YOUR
SCRUM TEAM?

9. WHAT DOES THIS MEAN FOR YOUR
SCRUM TEAM?
EVERYTHING!

10. 1. How much effort is spent during development
iterations fixing defects (a.k.a. bugs) that QA
finds which have been created or omitted by
developers?
How much project cost is spent on staffing QA
personnel to test and report defects?
How much money is spent paying developers to
eliminate defects in the code they originally
create?
ASK YOURSELF 3 QUESTIONS

11. 1. How much effort is spent during development
iterations fixing defects (a.k.a. bugs) that QA
finds which have been created or omitted by
developers?
2. How much project cost is spent on staffing QA
personnel to test and report defects?
How much money is spent paying developers to
eliminate defects in the code they originally
create?
ASK YOURSELF 3 QUESTIONS

12. 1. How much effort is spent during development
iterations fixing defects (a.k.a. bugs) that QA
finds which have been created or omitted by
developers?
2. How much project cost is spent on staffing QA
personnel to test and report defects?
3. How much money is spent paying developers to
eliminate defects in the code they originally
create?
ASK YOURSELF 3 QUESTIONS

13. HOW CAN THE BP EXAMPLE
HELP YOUR SCRUM TEAM?
• Like BP, Have Your Team Challenge The Status
Quo, That Defects In Code Is To Be Expected
• Set The SCRUM Team With
A Big Hairy Audacious Goal* Of:
ZER0 Defects
going into the
Quality Validation stage
* originated from “Built To Last: Successful Habits of Visionary Companies”, by James Collins and Jerry Porras

14. HAVING THE TEAM WORK UNDER A
BIG HAIRY AUDACIOUS GOALS (BHAG) *
LIKE ZERO DEFECTS, IS SIMPLISTIC BUT…
*BHAG originated from “Built To Last: Successful Habits of Visionary Companies”, by James Collins and Jerry Porras

15. WITHOUT EFFECTIVE SUPPORT,
IT’S USELESS
*BHAG originated from “Built To Last: Successful Habits of Visionary Companies”, by James Collins and Jerry Porras

16. SUPPORT THE GOAL OF ZERO DEFECTS
• Provide Support By Implementing
Test Requirement Driven Development(TREDD)
– Utilizing Quality Engineers members to partner
with Business Analysts to change acceptance
criteria to Test Requirements
– Developers now use Test Requirements to develop
AND validate their code BEFORE it goes into the
quality verification stage of the iteration

17. SCRUM TEAM STRIKES OIL!
Using TREDD, Your SCRUM Team Will:
Greatly Reduce Product Defects
It may not reach zero, just as BP still had dry wells; but it is
multiple times more efficient than how your SCRUM team is
currently working
Generate Cost Savings And Opportunities With
Staff Spending More Time on Development
Become Acutely Focused On Quality
Build Quality Into The Product
From The Beginning Through Defining And Implementing Test
Requirements

18. Help Your SCRUM Team Achieve More!
Learn about TREDD
Visit www.savvymgt.com/TREDD

19. www.SavvyMGT.com