Waste and Trashing

lsoftware developmentt
ft
ed a n l
Lean Software Development
L S ft D l t
Waste and Thrashing
mary@poppendieck.com Mary Poppendieck www.poppendieck.com

What is Waste?

Waste is…
is
Anything that depletes resources
of time, effort, space, or money
without adding customer value.
Value is…
is
Seen through the eyes of those
who pay for, use, support, or
p yf , , pp ,
derive value from our systems.

2 October 09
Put on Customer Glasses
Copyright©2009 Poppendieck.LLC l e a n

What is Waste?
Airline Statistics:
Available Seat Miles (ASM)
 A Capacity Measurement
Revenue Seat Miles (RSM)
 A Production Measurement
Load Factor = RSM/ASM
Put yourself in the shoes
y  A Utilization Measurement
of an airline executive: Re-phrasing the question:
Are empty seats waste? Will a higher load f
g factor

3
What do you think?
October 09 Copyright©2009 Poppendieck.LLC l e a n
increase profits?

Case Study
y
Customers Love Southwest By the Numbers* * Sources:
FAA Statistics
F i i
Excellent Customer Service Most Punctual SEC Filings
Fortune Rating
Reliable Performance Lost the Least Bags
Point to Point
Point-to-Point Routing Had the Fewest Complaints
Consistent Low Fares Rated “Most Admired” US Airline
No “Nuisance Charges” 35 Consecutive Years of Profitability
Lots f Fli ht O ti
L t of Flight Options Operates at the Lowest Load Factor
Flights On‐Time Performance Load Factors Cancelled Diverted
Carrier
Carrier 2007 2007 2006 2007 2006 2005 2004 2007 2007
WN ‐ Southwest Airlines   1,164,906 81.72% 84.66% 72.60% 73.10% 70.70% 69.50% 0.43% 0.12%
DL ‐Delta Air Lines 568,862 75.65% 75.72% 80.60% 78.50% 76.50% 74.70% 1.18% 0.21%
CO ‐ Continental Airlines   411,105 72.95% 76.54% 81.40% 80.70% 78.90% 76.90% 0.92% 0.35%

l e a n
NW ‐ Northwest Airlines   480,382 71.23% 79.02% 83.90% 84.00% 81.50% 79.20% 2.04% 0.13%
UA ‐ United Airlines   594,488 69.90% 74.79% 82.70% 82.10% 81.50% 79.30% 2.28% 0.10%
US ‐ US Airways   402,568 68.70% 78.51% 75.30% 78.30% 75.50% 75.10% 1.65% 0.08%
AA ‐ American Airlines    792,404 68.34% 78.33% 81.50% 80.00% 78.60% 74.80% 2.73% 0.09%
4 October 09 Copyright©2009 Poppendieck.LLC

Seeing Waste
g
The Seven Wastes of Manufacturing The 7 Wastes of
- T ii hi Oh
Taiichi Ohno Software D
S ft Development
l pm t

1. Overproduction 1. Extra Features
2. Motion 2. Handovers
3. Waiting
g 3. Failure Demand
4. Transportation 4. Technical Debt
5 Work In Process
5. 5 Task Switching
5.
6. Extra Processing 6. Delays

5
7. Defects
October 09
7. Defects

Extra Features
Features / Functions Used in a Typical System Cost of Complexity
p y
Often / Always Rarely / Never
Used: 20% Used: 64%

Sometimes Rarely 19%
16%

Cost
Often 13%

Always 7%

Never 45%

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman Time

l e a n
The Biggest opportunity f i
Th Bi t t it for increasing Software
i S ft
Development Productivity: Write Less Code!

Handovers
A handover occurs whenever we separate:*
p
 Responsibility − What to do
 Knowledge − How to do it
 Action − Actually doing it
 Feedback − Learning from results
*Allen Ward “Lean Product and Process Development”
Allen Lean Development

Whole Software
Development
p
QA and
Integration Team

l e a n
O ll
Overall
System Operations
and Support


Failure Demand

Value Demand
 Demand for work that adds value
from a customer perspective
p p
 The Goal: Delight Customers by
Responding to Value Demand
Failure Demand
 Demand on the resources
caused by your f il
db failures
 Eg. Support Calls
 The Goal: Eliminate Failure Demand

8
 Meanwhile, respond as fast as possible

Technical Debt
Anything that makes code difficult to change
y g ff g
 Sloppy / Un-testable Code
Code without a test harness is Legacy Code.

 Dependencies
High cohesion and low coupling
are essential for testable code.

 Unsynchronized Code Branches
The longer two code branches

l e a n
remain apart, the more difficult
h d ff l
they are to merge together.

Task Switching
g
10

Task A
Task B
Task C

Wasted Cost

Month 1 Month 2 Month 3 Month 4

Wasted Value
Value

Time
l e a n

Delays
y

11 October 09 Copyright©2009 Poppendieck.LLC l e a n

Defects
f


Q
Quality by Construction
y y
A Quality Process Builds Quality IN.
Q y Q y
 Rather than trying to test quality in later.
 If you find defects at the end of your process…
YYour process i d f i !
is defective!
Quality by Construction
 Code that reveals its intentions
 Design/code reviews
IImmediate, automated testing
di t t t d t ti
 STOP if the tests don’t pass!
 Continuous, nested integration
, g

13
 Escaped defect analysis & feedback

Dijkstra’s Challange
j g
If you want more effective programmers, you will discover
that they should not waste their time debugging – they
should not introduce bugs to start with.
How good are you?
When in your release cycle do you try to freeze code and test the system?
What percent of the release cycle remains for this “hardening”?
hardening ?
Top Companies: <10%
Typical: 30%

Sometimes: 50%

14 10/26/2009
Release Cycle

Buried in Work?

You are not alone!
Good
G d organizations that have solved most of their
i ti th t h l d t f th i
problems always seem to have one problem left:

15 October 09
Thrashing

What is Thrashing?
g
Thrashing:
A degenerate situation on a computer where increasing
resources are used to do a decreasing amount of work.
work
Well known in networking
and server operations.
d i
One of the most widely known
and studied instances of
Queuing Theory.

Queuing Theory 101

What are you doing about it?
y g

Ignore it and hope it will go away?
Insanity: Continuing to do the same thing

l e a n
and expecting d ff
d different results.
l

What Causes Thrashing?
g

Uneveness
Little’s Law
Time Through the System =
Number of Things in Process
Average Completion Rate


Reducing Cycle Time
g y

Optimize Throughput – Not Utilization
 Minimize the Number of Things In Process

Queuing Theory 101

Minimize the Number of
Things-in-Process
Things in Process
We have far too many things to do!
How long are your lists of things to get done?
How many things are in each list?
How long would it take to finish them?
How many will never get done?
Why are they in your queue?

Queues are buffers between departments that

l e a n
keep people from having to talk to each other!

What Causes Thrashing?
g
Overload
45
Cycle Time as a Function of Utilization and Batch Size*
40

35
Cycle Time (hours)

30 Large Batches
Medium Batches
25
Small Batches
e

20

15

10

5

0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

21
High Performance
*This assumes batch size is proportional to variability.
October 09 Copyright©2007 Poppendieck.LLC l e a nThrashing

Reducing Cycle Time
g y

 Minimize the Size of Things In Process

Queuing Theory 101

Minimize the Size of
Things-in-Process
Things in Process
Churn
 Do requirements keep changing?
You are specifying too early.
 Do you have test-and-fix cycles?
y y
You are testing too late.

Why do early specification and late
y y p f

23
testing seem like such a good idea?

Reducing Cycle Time
g y

Level the Workload
 Manage Workflows, not Schedules
Workflows

Queuing Theory 101

Empire State Building
p g
September 22, 1929
22 One Year Earlier:
Demolition started
January 22, 1930
Excavation started
March 17, 1930
Construction started
November 13, 1930
13
Exterior completed
May 1, 1931
Building opened
Exactly on time
18% under budget

How did they do it?
25 10/26/2009
The key: Focus on FLOW.

Steel Schedule
We thought of the work as if it
were a band marching through
the building and out the top.

26
From: “Building the Empire State”
Builders Notebook: Edited by Carol Willis
10/26/2009 Copyright©2009 Poppendieck.LLC l e a n

The Four Pacemakers

1.
1 Structural Steel Construction
 Completed September 22, 12 days early
2.
2 Concrete Floor Construction
 Completed October 22, 6 days early
3.
3 Exterior Metal Trim &Windows
 Completed October 17, 35 days early
4.
4 Exterior Li
E t i Limestone
t
 Completed November 13, 17 days early

27
From: “Building the Empire State”
Builders Notebook: Edited by Carol Willis
10/26/2009 Copyright©2009 Poppendieck.LLC l e a n

Key Success Factors
y
1. Teamwork of owner, architect, and builder
 Eliminated design loops by consulting experts early.
2. Deeply Experienced Builders
 Fixed Price Contract!
3. Focus on the key constraint: Material Flow
 500 trucks a day – no storage on site
4. Decoupling
 The pacemakers (and other systems) were designed to be independent
5. Cash Flow Thinking
 Every day of delay cost $10,000 ($120,000 today).
E d fd l t $10 000 ($120 000 t d )
6. Schedule was not laid out based on the details of the building design,
the building was designed based on the constraints of the situation.

l e a n
 T
Two acres of land in the middle of N Y k Cit zoning ordinances,
f l d i th iddl f New York City, i di
$35,000,000 of capital, the laws of physics, and a May 1, 1931 deadline.

28 10/26/2009 Copyright©2009 Poppendieck.LLC

Lessons

Design the system to meet the constraints;
do not derive constraints from the design.

Decouple workflows;
p ;
break dependencies!

Workflows are easier to control &

l e a n
more predictable than a schedules.
di bl h h d l

Reducing Cycle Time
g y

Level the Workload
Workflows
 Establish a Regular Cadence

Queuing Theory 101

Establish a Regular Cadence
g

Discovery Delivery

Daily

Stories
& Tests

One Iteration
Every 2-4
y
Ahead
Ah d
Weeks
Deployment
- Ready
Road Map: Software

l e a n
Prioritized
list of Done–D
Done–Done
D
desirable Ready–
Ready–Ready Feedback
features

Reducing Cycle Time
g y

Level the Workload
Workflows
Limit W k T C
Li it Work To Capacity
it
 Timebox, Don’t Scopebox

Queuing Theory 101

Timebox, Don’t Scopebox
p

The Iron Triangle: Cost, Schedule, and Scope
Cost Schedule
If you can’t meet all three – which one suffers?

Do not Ask: How
long will this take?
Cost

Ask instead: Wh t
A k i t d What can
be done by this date?

33 October 09
Time

Reducing Cycle Time
g y

Level the Workload
Workflows
Limit W k T C
it

l e a n
 P ll – D ’ P h
Pull Don’t Push
Queuing Theory 101

Pull Scheduling
Small Requests

Input Flow Output Capacity

Never

l e a n

Scheduling Large,
Multi-Team
Multi Team Products

Start 2 Months 5 Months 8 Months 11 Months 13 Months 15 Months
Product Review: Review: Action: Action: Review: First
Concept Customer Interest Proof of Concept Alpha Release Beta Release Beta Results Production
Approved
A d Decide:
D id Decide:
D id Decide:
D id Decide:
D id Decide:
D id Release
R l
Technical Approach Alpha Release Features Beta Release Features 1st Release Baseline 1st Release Final

Base Estimates on Experience and Data
Not Wishful Thinking
Timebox – Don’t Scopebox
p
 Ask NOT: How long will this take?
 Ask instead: What can be done by this date?
y
Integrating Events create cadence and pull

Reducing Cycle Time
g y

Level the Workload
Workflows
Limit W k T C
it

l e a n
 P ll – D ’ P h
Pull Don’t Push
Queuing Theory 101

lsoftware developmentt
ft
ed a n l
Thank You!
More Information: www.poppendieck.com

mary@poppendieck.com Mary Poppendieck www.poppendieck.com

Waste and Trashing

Recomendados

Recomendados

Más contenido relacionado

Similar a Waste and Trashing

Similar a Waste and Trashing (20)

Más de Agile Tour 2009 Québec

Más de Agile Tour 2009 Québec (11)

Último

Último (20)

Waste and Trashing