Contenu connexe Similaire à Waste and Trashing (20) Plus de Agile Tour 2009 Québec (11) Waste and Trashing1. 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
2. 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
3. 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?
4. 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
5. 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
Copyright©2009 Poppendieck.LLC l e a n
6. 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!
6 October 09 Copyright©2009 Poppendieck.LLC
7. 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
7 October 09 Copyright©2009 Poppendieck.LLC
8. 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
October 09 Copyright©2009 Poppendieck.LLC l e a n
9. 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.
9 October 09 Copyright©2009 Poppendieck.LLC
10. 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
11. Delays
y
11 October 09 Copyright©2009 Poppendieck.LLC l e a n
12. Defects
f
12 October 09 Copyright©2009 Poppendieck.LLC l e a n
13. 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
October 09 Copyright©2009 Poppendieck.LLC l e a n
14. 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
Copyright©2009 Poppendieck.LLC l e a n
15. 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
Copyright©2007 Poppendieck.LLC l e a n
16. 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.
16 October 09 Copyright©2007 Poppendieck.LLC l e a n
Queuing Theory 101
17. 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
17 October 09 Copyright©2007 Poppendieck.LLC
18. What Causes Thrashing?
g
Uneveness
Little’s Law
Time Through the System =
Number of Things in Process
Average Completion Rate
18 October 09 Copyright©2007 Poppendieck.LLC l e a n
19. Reducing Cycle Time
g y
Optimize Throughput – Not Utilization
Minimize the Number of Things In Process
19 October 09 Copyright©2008 Poppendieck.LLC l e a n
Queuing Theory 101
20. 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!
20 October 09 Copyright©2007 Poppendieck.LLC
21. 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
22. Reducing Cycle Time
g y
Optimize Throughput – Not Utilization
Minimize the Number of Things In Process
Minimize the Size of Things In Process
22 October 09 Copyright©2008 Poppendieck.LLC l e a n
Queuing Theory 101
23. 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?
October 09 Copyright©2007 Poppendieck.LLC l e a n
24. Reducing Cycle Time
g y
Optimize Throughput – Not Utilization
Minimize the Number of Things In Process
Minimize the Size of Things In Process
Level the Workload
Manage Workflows, not Schedules
Workflows
24 October 09 Copyright©2008 Poppendieck.LLC l e a n
Queuing Theory 101
25. 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.
Copyright©2009 Poppendieck.LLC l e a n
26. 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
27. 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
28. 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
29. 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
29 10/26/2009 Copyright©2009 Poppendieck.LLC
30. Reducing Cycle Time
g y
Optimize Throughput – Not Utilization
Minimize the Number of Things In Process
Minimize the Size of Things In Process
Level the Workload
Manage Workflows, not Schedules
Workflows
Establish a Regular Cadence
30 October 09 Copyright©2008 Poppendieck.LLC l e a n
Queuing Theory 101
31. 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
31 10/26/2009 Copyright©2009 Poppendieck.LLC
32. Reducing Cycle Time
g y
Optimize Throughput – Not Utilization
Minimize the Number of Things In Process
Minimize the Size of Things In Process
Level the Workload
Manage Workflows, not Schedules
Workflows
Establish a Regular Cadence
Limit W k T C
Li it Work To Capacity
it
Timebox, Don’t Scopebox
32 October 09 Copyright©2008 Poppendieck.LLC l e a n
Queuing Theory 101
33. 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
Copyright©2007 Poppendieck.LLC l e a n
34. Reducing Cycle Time
g y
Optimize Throughput – Not Utilization
Minimize the Number of Things In Process
Minimize the Size of Things In Process
Level the Workload
Manage Workflows, not Schedules
Workflows
Establish a Regular Cadence
Limit W k T C
Li it Work To Capacity
it
Timebox, Don’t Scopebox
l e a n
P ll – D ’ P h
Pull Don’t Push
Queuing Theory 101
34 October 09 Copyright©2008 Poppendieck.LLC
35. Pull Scheduling
Small Requests
Input Flow Output Capacity
Never
35 October 09 Copyright©2007 Poppendieck.LLC
l e a n
36. 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
36 October 09 Copyright©2009 Poppendieck.LLC l e a n
37. Reducing Cycle Time
g y
Optimize Throughput – Not Utilization
Minimize the Number of Things In Process
Minimize the Size of Things In Process
Level the Workload
Manage Workflows, not Schedules
Workflows
Establish a Regular Cadence
Limit W k T C
Li it Work To Capacity
it
Timebox, Don’t Scopebox
l e a n
P ll – D ’ P h
Pull Don’t Push
Queuing Theory 101
37 October 09 Copyright©2008 Poppendieck.LLC
38. lsoftware developmentt
ft
ed a n l
Thank You!
More Information: www.poppendieck.com
mary@poppendieck.com Mary Poppendieck www.poppendieck.com