Theory of Constraints
42 likes15,829 views
The document discusses the Theory of Constraints (TOC), which aims to improve flow, increase throughput, and reduce variation in systems by identifying, exploiting, and elevating their constraints. It outlines TOC's key assumptions and measures, and explains how TOC is similar to concepts in Kanban and Lean. The document suggests applying TOC to software development by focusing on flow rather than resource utilization, identifying potential bottlenecks, using cross-skilling to reduce waste, and removing failure demand to increase throughput.
Theory of Constraints
- 1. THEORY OF CONSTRAINTS Presented at St. Louis Limited WIP Society Jan 27, 2014 @mattphilip @StlLtdWIP Wednesday, January 29, 14
- 2. What is your goal? Wednesday, January 29, 14
- 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. 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. 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. “A system is strong as its weakest link” Wednesday, January 29, 14
- 7. “Every system has a bottleneck” Wednesday, January 29, 14
- 8. Analyze Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
- 9. Analyze Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
- 10. Analysis Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
- 11. Analysis Dev Test Deploy Every system has a bottleneck Wednesday, January 29, 14
- 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. THREE MEASURES • Throughput (up) • Operational expense (down) • Inventory Wednesday, January 29, 14 (down)
- 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. 1. IDENTIFY • Story walls help • cards not moving • build-up of cards (precedes constraint) • Cumulative-flow Wednesday, January 29, 14 diagram “Herbie!”
- 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. 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. 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. 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. SYSTEM DEMAND Wednesday, January 29, 14
- 21. NOT ALL DEMAND IS GOOD Revenue-Generating Demand Wednesday, January 29, 14 Failure Demand
- 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. Wednesday, January 29, 14
- 25. 50% system spent on failure demand Wednesday, January 29, 14
- 26. 50% system spent on failure demand Wednesday, January 29, 14
- 27. 50% system spent on failure demand Wednesday, January 29, 14
- 28. Increase in throughput by reducing failure demand Wednesday, January 29, 14
- 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. HOW DOES THEORY OF CONSTRAINTS FIT? Wednesday, January 29, 14
- 31. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14
- 32. KANBAN THEORY OF CONSTRAINTS Visualize Limit WIP Manage flow Make policies explicit Implement feedback loops Improve collaboratively Wednesday, January 29, 14 Identify
- 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. 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. 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. 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. 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. 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. What is your goal? Wednesday, January 29, 14
- 40. FURTHER READING Wednesday, January 29, 14