theory of constraints
DESCRIPTION
Theory of Constraints presented at the St. Louis Limited WIP Society, January 27, 2014. Based on Patrick Kua's original presentation.TRANSCRIPT
THEORY OF CONSTRAINTSPresented at
St. Louis Limited WIP SocietyJan 27, 2014
@mattphilip @StlLtdWIPWednesday, January 29, 14
What is your goal?
Wednesday, January 29, 14
WHY THEORY OF CONSTRAINTS?
• Improve flow time of product or service through the system
• Increase throughput
• Reduce variation, improve quality
• Low-disruption, sustainable way to change
Wednesday, January 29, 14
WHY THEORY OF CONSTRAINTS?
• Improve flow time of product or service through the system
• Increase throughput
• Reduce variation, improve quality
• Low-disruption, sustainable way to change Achieve the goal!
Wednesday, January 29, 14
ASSUMPTIONS
• Org values speed and volume as determinants of success
• Current processes are essential to produce the desired output
• Product or service design is stable, economical and essentially correct and satisfies customers
• Management structure supports and values change
• Process has dependent events and fluctuations/variation
Wednesday, January 29, 14
“A system is strong as its weakest link”
Wednesday, January 29, 14
“Every system has a bottleneck”
Wednesday, January 29, 14
Analyze Dev Test Deploy
Every system has a bottleneckWednesday, January 29, 14
Analyze Dev Test Deploy
Every system has a bottleneckWednesday, January 29, 14
Analysis Dev Test Deploy
Every system has a bottleneckWednesday, January 29, 14
Analysis Dev Test Deploy
Every system has a bottleneckWednesday, January 29, 14
“An hour lost at a bottleneck is an hour lost for the total system. An hour saved at a non-‐
bottleneck is just a mirage.”
Iteration 0 1 2 3 4
Analysis + Design
Development
Testing + Showcase
Integration + QA Release and operation
Customer
Centralized QA IT Operations
"Agile" team
The "last mile"
Wednesday, January 29, 14
THREE MEASURES
• Throughput (up)
• Operational expense (down)
• Inventory (down)
Wednesday, January 29, 14
FIVE FOCUSING STEPS
1. Identify the constraint
2. Exploit the constraint
3. Subordinate everything else to the constraint
4. Elevate the constraint
5. Repeat step 1
Wednesday, January 29, 14
1. IDENTIFY
• Story walls help
• cards not moving
• build-up of cards (precedes constraint)
• Cumulative-flow diagram“Herbie!”
Wednesday, January 29, 14
2. EXPLOIT
• Is the bottleneck only working on “value added” work?
• Reduce failure demand
• Could be simple change in policy
• Do not resort to expensive upgrades or changes “Go faster,
Herbie!”
Wednesday, January 29, 14
3. SUBORDINATE
• Adjust speed and/or WIP of subordinate processes (usually upstream)
• Keep small backlog before bottleneck to ensure value-added work is always available to it (never starve the bottleneck)
• Kaizen with spare capacity
• Training/cross-skilling“Everyone walk behind Herbie!”
Wednesday, January 29, 14
4. ELEVATE
• Root-cause analysis
• Only do as “last possible” option: Whatever is necessary to eliminate constraint
• Increase capacity (adds complexity, communication cost, etc.) “Share Herbie’s
backpack load!”
Wednesday, January 29, 14
5. REPEAT
• Constraint is “testable” by reviewing the measures:
• Throughput (up)
• Operational Expense (down)
• Inventory/WIP (down)
• Find the new constraint
Wednesday, January 29, 14
SYSTEM DEMAND
Wednesday, January 29, 14
NOT ALL DEMAND IS GOOD
Failure DemandRevenue-GeneratingDemand
Wednesday, January 29, 14
NOT ALL DEMAND IS GOOD
Failure DemandRevenue-GeneratingDemand
“Failure to do something right the first time” -‐ John Seddon
Wednesday, January 29, 14
Wednesday, January 29, 14
Story
Bug
Wednesday, January 29, 14
50% system spent on failure demand
Wednesday, January 29, 14
50% system spent on failure demand
Wednesday, January 29, 14
50% system spent on failure demand
Wednesday, January 29, 14
Increase in throughput by reducing failure demand
Wednesday, January 29, 14
FAILURE DEMAND IN SOFTWARE
• Bugs
• Features you do not need
• Poor user experience (results in more features, support needs)
• Too much up-front planning (results in constant backlog rework)
• Complex product/technology choice
Wednesday, January 29, 14
HOW DOES THEORY OF CONSTRAINTS
FIT?
Wednesday, January 29, 14
KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively
THEORY OF CONSTRAINTS
Wednesday, January 29, 14
KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively
THEORY OF CONSTRAINTS
Identify
Wednesday, January 29, 14
KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively
THEORY OF CONSTRAINTS
Identify
Exploit
Wednesday, January 29, 14
KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively
THEORY OF CONSTRAINTS
Identify
SubordinateExploit
Wednesday, January 29, 14
KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively
THEORY OF CONSTRAINTS
Identify
SubordinateElevate
Exploit
Wednesday, January 29, 14
KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively
THEORY OF CONSTRAINTS
Identify
SubordinateElevateRepeat
Exploit
Wednesday, January 29, 14
LEAN AND TOCTheory Lean Theory of Constraints
Main idea
Assumptions
FocusPrimary effect
Secondary effects
Remove waste Reduce constraints
Removing waste improves performance
Many small improvements are better than systems analysis
Improving speed, volume is goodExisting systems are correctProcess interdependence
Flow System constraintsReduced flow time Increased throughput
Less variationLess inventory/waste
Improved qualityDifferent performance measures (flow, throughput)
Less variationLess inventory/waste
Improved qualityDifferent performance measures (flow, throughput)
Wednesday, January 29, 14
APPLYING TOC TOSOFTWARE DEVELOPMENT
• Improve until you can no more before adding capacity
• Focus on moving work through the “pipe” (flow rather than utilization)
• Find “pile-ups” as potential improvement areas to investigate and prioritize.
• Use excess capacity at non-bottlenecks to cross-skill
• Remove failure demand to increase throughput
Wednesday, January 29, 14
What is your goal?
Wednesday, January 29, 14
FURTHER READING
Wednesday, January 29, 14