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.

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

24. Story
Bug
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