Attack Sources of Variability to Improve Predictability

Attack Sources of Variability to Improve Predictability

Kanban Recipe for Success: Step Six

Jason Yipj.c.yip@computer.org

jcyip@thoughtworks.com@jchyip

http://jchyip.blogspot.com

HOMEWORK CHECK

What step(s) did you take to start prioritising?

The Recipe for Success

1. Focus on Quality2. Reduce WIP3. Deliver Often4. Balance Demand Against Throughput5. Prioritise6. Attack Variability to Improve

Predictability

WHAT IS VARIABILITY?

WHY VARIABILITY?

“We cannot add value without adding variability, but we can add variability without adding value.”

Don Reinertsen, The Principles of Product Development Flow

“Variability results in more work-in-progress and longer lead times.”

David Anderson, Kanban

Variability leads to buffers and bottlenecks

http://flic.kr/p/4QofnD

“Consistency leads to better programs. If formatting varies unpredictably, or a loop over an array runs uphill this time and downhill the next, or strings are copied with strcpy here and a for loop there, the variations make it harder to see what’s really going on. But if the same computation is done the same way every time it appears, any variation suggests a genuine difference, one worth noting.”

Brian Kernighan and Rob Pike, The Practice of Programming

Paying attention to variability helps you to see problems

SOURCES OF VARIABILITY

Types of variation• Internal

– Due to the design of the system– Variation is random with no clear assignable cause– Address this by changing the policies and process (aka

“rules of the game”)

• External– Variation caused by events or aspects that are outside your

control– It is possible to assign a cause (aka the external event)– Address this by having systems and structures to “roll with

it” (aka risk management)

Various ways to talk about variation

• Shewart– Chance-cause (random and inherent to system design) vs assignable-

cause (cause-and-effect with external event)

• Alpert / Deming– Common-cause (common to all similarly designed systems) vs

special-cause (new knowledge or event that is different to how the system normally works)

• Feigenbaum– Usual (the variation you’ve learned to expect) vs unusual (any

variation that is not expected) (Also normal vs abnormal)

• Wheeler– Routine (predictable variation characteristic of common causes) vs

exceptional (unpredictable variation as the result of an assignable cause)

http://jchyip.blogspot.com.au/2010/05/different-ways-to-describe-causes-of.html

Internal sources of variability in software development

• Software development process• Project management process• Organisational systems and

structures• Capability of team members• Technology choice

“Simply changing an existing process policy can dramatically reduce sources of variability that affect predictability.”

David Anderson, Kanban

ASIDE: VARIATION IS NOT INHERENTLY EVIL

“We cannot add value without adding variability, but we can add variability without adding value.”

Don Reinertsen, The Principles of Product Development Flow

Which choice has the least variability?

Choice Stakes Payoff Probability

A $15 000 $100 000 50%

B $15 000 $20 000 90%

C $15 000 $16 000 100%

Derived from The Principles of Product Development Flow by Don Reinertsen

Which is the best economic choice?

Choice Stakes Payoff Probability Expected Value

A $15 000 $100 000 50% $35 000

B $15 000 $20 000 90% $3 000

C $15 000 $16 000 100% $1 000

Derived from The Principles of Product Development Flow by Don Reinertsen

Higher variability raises pay-off

From The Principles of Product Development Flow by Don Reinertsen

Don’t “minimise variability” nor “maximise variability”

but rather optimise variability based on context

Don Reinertsen’s two main approaches for dealing with variability

1. Change the amount of variability2. Change the economic consequences

of the variability

TACTICS FOR REDUCING VARIABILITY

Standardise work item size

• Standardise the format (e.g., As a…I want…in order to…)

• Limit the number of types (e.g., S, M, L vs 0 – 100)

Which betting approach has less variation?

1. Flip a coin. Heads, you win $100; tails, you lose $100.

2. Flip a coin 4 times. Each time you flip, heads, you win $25; tails, you lose $25.

Option 1: Chance of losing $100 is 50% (1 in 2)Option 2: Chance of losing $100 is 6.25% (1 in 16)

Derived from The Principles of Product Development Flow by Don Reinertsen

Many small experiments produce less variation than one big one

If it varies too much, do it more often

http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

Automate

Practice

Reuse

… but decide based on economics, not “maximising reuse”

http://en.wikipedia.org/wiki/Vacuum_tube

Pursue high quality

• Peer reviews• Pair programming• Unit tests• Continuous integration• Small batch sizes• Highly cohesive, loosely coupled

architectures

Remove unnecessary ambiguity

Put limits on expedite requests

Process behaviour (aka control) charts

TACTICS FOR IMPROVING THE CONSEQUENCES OF VARIABILITY

“A [schedule] buffer converts uncertain earliness to certain lateness. Thus, it is generally a bad idea to trade cycle time for reduced variability in cycle time.”

Don Reinertsen, The Principles of Product Development Flow

Rapid feedback

• Think Mean Time to Recover vs Mean Time to Failure

Substitute cheap variability for expensive variability

From The Principles of Product Development Flow by Don Reinertsen

HOMEWORK

What is the smallest step you could take to move 1

level up (or more)?

What is your plan to start that step tomorrow?