theory of constraints

Post on 08-May-2015

1.434 Views

Category:

Business

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

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

TRANSCRIPT

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

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 Achieve the goal!

Wednesday, January 29, 14

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

Wednesday, January 29, 14

“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 bottleneckWednesday, January 29, 14

Analyze Dev Test Deploy

Every system has a bottleneckWednesday, January 29, 14

Analysis Dev Test Deploy

Every system has a bottleneckWednesday, January 29, 14

Analysis Dev Test Deploy

Every system has a bottleneckWednesday, 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.”

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"

Wednesday, January 29, 14

THREE MEASURES

• Throughput (up)

• Operational expense (down)

• Inventory (down)

Wednesday, January 29, 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

1. IDENTIFY

• Story walls help

• cards not moving

• build-up of cards (precedes constraint)

• Cumulative-flow diagram“Herbie!”

Wednesday, January 29, 14

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

Wednesday, January 29, 14

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

Wednesday, January 29, 14

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

5. REPEAT

• Constraint is “testable” by reviewing the measures:

• Throughput (up)

• Operational Expense (down)

• Inventory/WIP (down)

• Find the new constraint

Wednesday, January 29, 14

SYSTEM DEMAND

Wednesday, January 29, 14

NOT ALL DEMAND IS GOOD

Failure DemandRevenue-GeneratingDemand

Wednesday, January 29, 14

NOT ALL DEMAND IS GOOD

Failure DemandRevenue-GeneratingDemand

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

Wednesday, January 29, 14

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 needs)

• Too much up-front planning (results in constant backlog rework)

• Complex product/technology choice

Wednesday, January 29, 14

HOW DOES THEORY OF CONSTRAINTS

FIT?

Wednesday, January 29, 14

KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively

THEORY OF CONSTRAINTS

Wednesday, January 29, 14

KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively

THEORY OF CONSTRAINTS

Identify

Wednesday, January 29, 14

KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively

THEORY OF CONSTRAINTS

Identify

Exploit

Wednesday, January 29, 14

KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively

THEORY OF CONSTRAINTS

Identify

SubordinateExploit

Wednesday, January 29, 14

KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively

THEORY OF CONSTRAINTS

Identify

SubordinateElevate

Exploit

Wednesday, January 29, 14

KANBANVisualizeLimit WIPManage flowMake policies explicitImplement feedback loopsImprove collaboratively

THEORY OF CONSTRAINTS

Identify

SubordinateElevateRepeat

Exploit

Wednesday, January 29, 14

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)

Wednesday, January 29, 14

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

Wednesday, January 29, 14

What is your goal?

Wednesday, January 29, 14

FURTHER READING

Wednesday, January 29, 14

top related