Theory of Constraints

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


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!


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


“A system is strong as its weakest link”


“Every system has a bottleneck”


Analyze Dev Test Deploy

Every system has a bottleneckWednesday, January 29, 14

Analyze Dev Test Deploy


Analysis Dev Test Deploy


Analysis Dev Test Deploy


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


THREE MEASURES

• Throughput (up)

• Operational expense (down)

• Inventory (down)


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


1. IDENTIFY

• Story walls help

• cards not moving

• build-up of cards (precedes constraint)

• Cumulative-flow diagram“Herbie!”


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!”


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!”


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!”


5. REPEAT

• Constraint is “testable” by reviewing the measures:

• Throughput (up)

• Operational Expense (down)

• Inventory/WIP (down)

• Find the new constraint


SYSTEM DEMAND


NOT ALL DEMAND IS GOOD

Failure DemandRevenue-GeneratingDemand


NOT ALL DEMAND IS GOOD

Failure DemandRevenue-GeneratingDemand

“Failure to do something right the first time” -‐ John Seddon



Story

Bug


50% system spent on failure demand






Increase in throughput by reducing failure demand


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


HOW DOES THEORY OF CONSTRAINTS

FIT?


KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively

THEORY OF CONSTRAINTS




Identify




Identify

Exploit




Identify

SubordinateExploit




Identify

SubordinateElevate

Exploit




Identify

SubordinateElevateRepeat

Exploit


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)


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


What is your goal?


FURTHER READING


Business

Theory of Constraints