Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
THEORY OF CONSTRAINTS
Presented at
St. Louis Limited WIP Society
Jan 27, 2014

@mattphilip @StlLtdWIP
Wednesday, January 2...
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
...
WHY
THEORY OF CONSTRAINTS?
• Improve

flow time of product or service through the system

• Increase

throughput

• Reduce
...
ASSUMPTIONS
• Org

values speed and volume as determinants of success

• Current

processes are essential to produce the d...
“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 bottleneck
Wednesday, January 29, 14
Analyze

Dev

Test

Deploy

Every system has a bottleneck
Wednesday, January 29, 14
Analysis

Dev

Test

Deploy

Every system has a bottleneck
Wednesday, January 29, 14
Analysis

Dev

Test

Deploy

Every system has a bottleneck
Wednesday, 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.”...
THREE MEASURES

• Throughput

(up)

• Operational

expense (down)

• Inventory

Wednesday, January 29, 14

(down)
FIVE FOCUSING STEPS
1. Identify the constraint
2. Exploit the constraint
3. Subordinate everything else to the constraint
...
1. IDENTIFY

• Story

walls help

• cards

not moving

• build-up

of cards (precedes constraint)

• Cumulative-flow

Wedne...
2. EXPLOIT
• Is

the bottleneck only working on “value added” work?

• Reduce
• Could

failure demand

be simple change in...
3. SUBORDINATE
• Adjust

speed and/or WIP of subordinate processes (usually
upstream)

• Keep

small backlog before bottle...
4. ELEVATE
• Root-cause

analysis

• Only

do as “last possible” option: Whatever is necessary to
eliminate constraint

• ...
5. REPEAT
• Constraint

is “testable” by reviewing the measures:

• Throughput

(up)

• Operational

Expense (down)

• Inv...
SYSTEM DEMAND

Wednesday, January 29, 14
NOT ALL DEMAND IS GOOD

Revenue-Generating
Demand

Wednesday, January 29, 14

Failure Demand
NOT ALL DEMAND IS GOOD

Revenue-Generating
Demand

Failure Demand

“Failure to do something
right the first time” -‐ John ...
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
...
HOW DOES
THEORY OF CONSTRAINTS
FIT?

Wednesday, January 29, 14
KANBAN

THEORY OF
CONSTRAINTS

Visualize
Limit WIP
Manage flow
Make policies explicit
Implement feedback loops
Improve coll...
KANBAN

THEORY OF
CONSTRAINTS

Visualize
Limit WIP
Manage flow
Make policies explicit
Implement feedback loops
Improve coll...
KANBAN

THEORY OF
CONSTRAINTS

Visualize
Limit WIP
Manage flow
Make policies explicit
Implement feedback loops
Improve coll...
KANBAN

THEORY OF
CONSTRAINTS

Visualize
Limit WIP
Manage flow
Make policies explicit
Implement feedback loops
Improve coll...
KANBAN

THEORY OF
CONSTRAINTS

Visualize
Limit WIP
Manage flow
Make policies explicit
Implement feedback loops
Improve coll...
KANBAN

THEORY OF
CONSTRAINTS

Visualize
Limit WIP
Manage flow
Make policies explicit
Implement feedback loops
Improve coll...
LEAN AND TOC
Theory

Lean

Theory of Constraints

Main idea

Remove waste

Reduce constraints

Assumptions

Removing waste...
APPLYING TOC TO
SOFTWARE DEVELOPMENT
• Improve

until you can no more before adding capacity

• Focus

on moving work thro...
What is your goal?

Wednesday, January 29, 14
FURTHER READING

Wednesday, January 29, 14
Upcoming SlideShare
Loading in …5
×

Theory of Constraints

Theory of Constraints presented at the St. Louis Limited WIP Society, January 27, 2014. Based on Patrick Kua's original presentation.

Theory of Constraints

  1. 1. THEORY OF CONSTRAINTS Presented at St. Louis Limited WIP Society Jan 27, 2014 @mattphilip @StlLtdWIP Wednesday, January 29, 14
  2. 2. What is your goal? Wednesday, January 29, 14
  3. 3. WHY THEORY OF CONSTRAINTS? • Improve flow time of product or service through the system • Increase throughput • Reduce variation, improve quality • Low-disruption, sustainable Wednesday, January 29, 14 way to change
  4. 4. 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
  5. 5. 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 • Process Wednesday, January 29, 14 structure supports and values change has dependent events and fluctuations/variation
  6. 6. “A system is strong as its weakest link” Wednesday, January 29, 14
  7. 7. “Every system has a bottleneck” Wednesday, January 29, 14
  8. 8. Analyze Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
  9. 9. Analyze Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
  10. 10. Analysis Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
  11. 11. Analysis Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
  12. 12. “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.” "Agile" team Analysis + Design Centralized QA IT Operations Development Integration + QA Release and operation Testing + Showcase Customer Iteration Wednesday, January 29, 14 0 1 2 3 4 The "last mile"
  13. 13. THREE MEASURES • Throughput (up) • Operational expense (down) • Inventory Wednesday, January 29, 14 (down)
  14. 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
  15. 15. 1. IDENTIFY • Story walls help • cards not moving • build-up of cards (precedes constraint) • Cumulative-flow Wednesday, January 29, 14 diagram “Herbie!”
  16. 16. 2. EXPLOIT • Is the bottleneck only working on “value added” work? • Reduce • Could failure demand be simple change in policy • Do not resort to expensive upgrades or changes Wednesday, January 29, 14 “Go faster, Herbie!”
  17. 17. 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 Wednesday, January 29, 14 “Everyone walk behind Herbie!”
  18. 18. 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
  19. 19. 5. REPEAT • Constraint is “testable” by reviewing the measures: • Throughput (up) • Operational Expense (down) • Inventory/WIP • Find (down) the new constraint Wednesday, January 29, 14
  20. 20. SYSTEM DEMAND Wednesday, January 29, 14
  21. 21. NOT ALL DEMAND IS GOOD Revenue-Generating Demand Wednesday, January 29, 14 Failure Demand
  22. 22. NOT ALL DEMAND IS GOOD Revenue-Generating Demand Failure Demand “Failure to do something right the first time” -‐ John Seddon Wednesday, January 29, 14
  23. 23. Wednesday, January 29, 14
  24. 24. Story Bug Wednesday, January 29, 14
  25. 25. 50% system spent on failure demand Wednesday, January 29, 14
  26. 26. 50% system spent on failure demand Wednesday, January 29, 14
  27. 27. 50% system spent on failure demand Wednesday, January 29, 14
  28. 28. Increase in throughput by reducing failure demand Wednesday, January 29, 14
  29. 29. 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 Wednesday, January 29, 14 product/technology choice
  30. 30. HOW DOES THEORY OF CONSTRAINTS FIT? Wednesday, January 29, 14
  31. 31. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14
  32. 32. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14 Identify
  33. 33. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14 Identify Exploit
  34. 34. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14 Identify Exploit Subordinate
  35. 35. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14 Identify Exploit Subordinate Elevate
  36. 36. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14 Identify Exploit Subordinate Elevate Repeat
  37. 37. LEAN AND TOC Theory Lean Theory of Constraints Main idea Remove waste Reduce constraints Assumptions Removing waste improves Improving speed, volume is good performance Existing systems are correct Many small improvements are better Process interdependence than systems analysis Focus Flow System constraints Primary effect Reduced flow time Increased throughput Secondary effects Wednesday, January 29, 14 Less variation Less inventory/waste Improved quality Different performance measures (flow, throughput)
  38. 38. APPLYING TOC TO SOFTWARE 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 and prioritize. • Use potential improvement areas to investigate excess capacity at non-bottlenecks to cross-skill • Remove Wednesday, January 29, 14 failure demand to increase throughput
  39. 39. What is your goal? Wednesday, January 29, 14
  40. 40. FURTHER READING Wednesday, January 29, 14

×