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.
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
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"
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
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
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
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