Sydney Limited WIP Society presentation on Kanban Recipe of Success part 6: Attack Sources of Variability to Improve Predictability. What is variation? Why do we care about variation? When is variation valuable? Tactics to changing the amount of variation. Tactics to change the consequences of variation.

1. Attack Sources of Variability to
Improve Predictability
Kanban Recipe for Success: Step Six
Jason Yip
j.c.yip@computer.org
jcyip@thoughtworks.com
@jchyip
http://jchyip.blogspot.com

2. HOMEWORK CHECK

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

4. The Recipe for Success
1.
2.
3.
4.
5.
6.
Focus on Quality
Reduce WIP
Deliver Often
Balance Demand Against Throughput
Prioritise
Attack Variability to Improve
Predictability

5. WHAT IS VARIABILITY?

7. WHY VARIABILITY?

8. “We cannot add value without
adding variability, but we can
add variability without adding
value.”
Don Reinertsen, The Principles
of Product Development Flow

9. “Variability results in more workin-progress and longer lead
times.”
David Anderson, Kanban

10. Variability leads to buffers and
bottlenecks
http://flic.kr/p/4QofnD

11. “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

12. Paying attention to variability helps
you to see problems

13. SOURCES OF VARIABILITY

14. 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)

15. Various ways to talk about
variation
• Shewart
– Chance-cause (random and inherent to system design) vs assignablecause (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

16. Internal sources of variability in
software development
•
•
•
•
•
Software development process
Project management process
Organisational systems and structures
Capability of team members
Technology choice

17. “Simply changing an existing
process policy can dramatically
reduce sources of variability that
affect predictability.”
David Anderson, Kanban

18. ASIDE: VARIATION IS NOT
INHERENTLY EVIL

19. “We cannot add value without
adding variability, but we can
add variability without adding
value.”
Don Reinertsen, The Principles
of Product Development Flow

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

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

22. Higher variability raises pay-off
From The Principles of Product Development Flow by Don Reinertsen

23. Don’t “minimise variability” nor
“maximise variability” but rather
optimise variability based on
context

24. Don Reinertsen’s two main
approaches for dealing with
variability
1. Change the amount of variability
2. Change the economic consequences of
the variability

25. TACTICS FOR REDUCING
VARIABILITY

26. 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)

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

28. Many small experiments produce
less variation than one big one

29. If it varies too much, do it more
often
Automate
Practice
http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

30. Reuse
… but decide based on economics, not
“maximising reuse”
http://en.wikipedia.org/wiki/Vacuum_tube

31. Pursue high quality
•
•
•
•
•
•
Peer reviews
Pair programming
Unit tests
Continuous integration
Small batch sizes
Highly cohesive, loosely coupled
architectures

32. Remove unnecessary ambiguity

33. Put limits on expedite requests

34. Process behaviour (aka control)
charts

35. TACTICS FOR IMPROVING THE
CONSEQUENCES OF VARIABILITY

36. “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

37. Rapid feedback
• Think Mean Time to Recover vs Mean
Time to Failure

38. Substitute cheap variability for
expensive variability
From The Principles of Product Development Flow by Don Reinertsen

39. HOMEWORK

41. What is the smallest step you
could take to move 1 level up
(or more)?

42. What is your plan to start that
step tomorrow?