Key Note - Lean Kanban North America 2013 - Beyond Kanban

Beyond Kanban
Managing Investment in Knowledge
Work against Business Risks

Kanban enabled
qualitative and
quantitative risk
management
David J. Anderson
Raymond Keating
Lean Kanban Conference
Chicago, 1st May 2013

dja@djaa.com, @djaa_dja

Part 1 - Introduction


Some Core Kanban Concepts


Commitment is deferred
Backlog
Pool
of
Ideas

Engineering
Ready

5

Testing

UAT

3

5

3

∞

Ongoing

Done

Items in the backlog remain
optional and unprioritized

Change
Requests

Pull

F F
F
F F
F
F

Development

Test
Ready

D
G

Wish to avoid discard after commitment

PTCs

Commitment point


E

We are committing to getting
started. We are certain we want
to take delivery.

I

Deployment
Ready
∞

Discard rates are often high
Pool
of
Ideas

Engineering
Ready

5

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

The discard rate with XIT was 48%.
~50% is commonly observed.

Change
Requests

F F
F
F
G
Reject

Deferring commitment and
Options have value because the
avoiding interrupting
future is
Dworkersuncertain
for estimates
E
0%makes rate implies there is
discard sense when discard
no uncertainty about the future
rates are high!

PTCs

I

Discarded

I

Deployment
Ready
∞

Upstream Kanban Prepares Options
Pool
of
Ideas

Biz
Case
Dev

Requirements
Analysis

Ready
for
Engineering

∞

24 - 48

12 - 24

4 - 12

K
L

Min & Max limits
insure sufficient
options are always
available

Committed

4

Development

Testing

3

3

Ongoing

Done

Verification

J
I

D

F
Options
$$$ cost of acquiring options
Reject

Discarded

O

P

Q
Commitment point


Committed Work

Replenishment Frequency
Pool
of
Ideas

Engineering
Ready

5

Replenishment
Change
Requests

Pull

F F
F
F F
F
F

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

Frequent replenishment is
more agile.

On-demand replenishment is
D
most agile!
G

PTCs

Discarded

I

E
The frequency of system
replenishment should reflect
arrival rate of new
information and the
transaction & coordination
I
costs of holding a meeting

Deployment
Ready
∞

Delivery Frequency
Pool
of
Ideas
Change
Requests

Pull

F F
F
F F
F
F

Engineering
Ready

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

Frequent deployment is
more agile.

5

Deployment buffer size can
On-demand deployment
reduce as frequency of
D deliveryagile!
most increases

G

PTCs

Discarded

I

is

E
The frequency of delivery
should reflect the transaction
& coordination costs of
deployment plus costs &
toleranceI of customer to take
delivery

Deployment
Ready
∞

Delivery

Specific delivery commitment may be
deferred even later
DeployEnginPool
of
Ideas

eering
Ready

5

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

ment
Ready
∞

Change
Requests

Pull

F F
F
F F
F
F

D
G

E

PTCs

We are now committing to a
specific deployment and
delivery date

Discarded

*This may happen earlier if
I
circumstances demand it

I

2nd
Commitment
point*

Defining Kanban System Lead Time
Pool
of
Ideas

Engineering
Ready

5

Deployment
Ready
∞

The clockTest
starts ticking when
UAT
we
customers
Ready
Development accept the Testing
is
5
∞
3 order, not when it 3 placed!
Ongoing
Done
Until then customer orders are
merely available options

Change
Requests

Pull

F F
F
F F
F
F

D
G

E

System Lead Time

PTCs

I

Discarded

I

Lead time
ends when
the item
reaches the

first ∞
queue.

Little’s Law & Cumulative Flow
Delivery Rate

Pool
of
Ideas

=

Lead Time

Avg. Lead Time
WIP


WIP

Ready
To
Deploy

Avg. Delivery Rate

Flow the
Efficiency
Flow efficiency measures

Pool
Enginpercentage of total lead time
of spent actually adding value
eering
is
Development
Ideas
Ready

(or knowledge) versus waiting
3
Ongoing

2

Done

Testing

3

Verification Acceptance

Deployment
Ready
∞

Until then customer orders are
merely available options
Flow efficiency = Work Time

Multitasking means time spent
E in working columns is often
waiting time

PB
GY

DE

Waiting Working

MN
AB

Waiting

Working

Waiting

Lead Time
* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012


x 100%

Lead Time

Flow efficiencies of 2% have been
F
reported*. 5% -> 15% D normal, P1
is
>
40% is good!
G

I

Done

Observe Lead Time Distribution as an enabler
of a Probabilistic Approach to Management
Lead Time Distribution
3.5
3

CRs & Bugs

2.5
2
1.5
1
0.5

1

4

7

0

3

6

8
14

14

13

12

12

11

10

99

92

85

78

71

64

57

50

43

36

29

22

8

15

1

0

Days

This is multi-modal data!

Mean of 31
days

The workexpectation of
SLA is of two types:
Change Requests (new
105 and Production
features);days with 98 %
Defects

SLA expectation of
44 days with 85% on-time

on-time

Mean
5 days

Change Requests

Production Defects

Filter Lead Time data by Type of Work (and
Class of Service) to get Single Mode
Distributions

98% at
25 days
85% at
10 days


98% at
150 days

Mean
50 days

85% at
60 days

Allocate Capacity to Types of Work
Pool
of
Ideas

Engineering
Ready

Ongoing

2
Change
Requests

Development

4

3

Done

Testing

3


Consistent capacity allocation
E
some consistency to
should bring more consistency to
MN
delivery rate of work of each
D
AB
type

F

Lead Time

PB
DE
Productio
n
Defects

I

Deployment
Ready

3

G

P1

GY


Separate understanding of
Separate understanding of Lead
Lead Time for each type of
Time for each type of work
work
Lead Time

∞

Done

Defining Customer Lead Time
Pool
of
Ideas

Engineering
Ready

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

5

Change
Requests

Done

The clock still starts ticking
when we accept the customers
order, not when it is placed!

Deployment
Ready
∞

Pull

F F
F
F F
F
F

D
G

E

Customer Lead Time

PTCs

Discarded

I

The frequency of delivery
cadence will affect customer
I
lead time in addition to system
capability

Done
∞

impact

The Optimal Time to Start
If we start too early, we forgo
the option and opportunity to do
something else that may provide
value.
If we start too late we risk
Ideal Start
incurring the cost of delay

time
When we
need it

Here

With a 6 in 7 chance of on-time
delivery, we can always expedite
to insure on-time delivery
85th
percentile
Commitment point


Part 2
Qualitative Risk Management


The Key to Governance of
Portfolio Risk


Simplifying Alignment & Corporate
Governance
Kanban systems enable a
Our business has defined promises to our greatly
shareholders in terms of model forservices
simplified the products, management
and markets we operate within and our
of risk & corporate governance
tolerance to risk.
If we can show that we develop good, innovative
ideas within those bounds and that our people
are always working on the best of those
available choices, we can claim appropriate use
of shareholders’ funds


Risk #1 Are we creating the right ideas?
Pool
of
Ideas

Biz
Case
Dev

Requirements
Analysis

Ready
for
Engineering

∞

24 - 48

12 - 24

4 - 12

W

Q

X

ZS

R

Y

T
AA
U

K

L

Q
R
S

FT

J

I
U1 U

Committed

4

Development

Testing

3

3

Ongoing

K
L
J
F
I
D

Ideas should reflect
opportunities to
exploit
& be classified by the
business risks they
Commitment point
address

Done

Verification

Risk #2 What to Pull Next?
Pool
of
Ideas

Biz
Case
Dev

Requirements
Analysis

Ready
for
Engineering

∞

24 - 48

12 - 24

4 - 12

Committed

4

Development

Testing

3

3

Ongoing

Done

I have 4

options, which
one should I
Replenishing the system is an act of commitment
K
choose?
J
– selecting items for delivery – for conversion
L
from options into real value.
Pull
Pull Selection is choosing from immediate
Pull
I
options – ideally dynamic selection of the item
with the most immediate risk attached to it by a
D
suitably skilled F
member of the team
Replenishment

Pull
Selection

Commitment point

Risk Assessment


A Lean approach to alignment with business
risks uses Qualitative Assessment
But how do we determine the risks in
We need a work item that we must manage?
a fast, cheap, accurate, consensus

forming approach to risk assessment. We need
Lean Risk Assessment!

The answer is to use a set of qualitative
methods to assess different dimensions of risk
such as urgency


Sketch market payoff function
Room nights
sold per day

Cost of delay for an online Easter holiday marketing
promotion is difference in integral between the two curves

Estimated additional
rooms sold
Cost of delay
Actual rooms sold

time
When we need it


When it arrived

impact

Cost of Delay based on Market Payoff
Sketches
Treat as a Standard Class item
Total cost
of delay

time
Cost of delay function for an online Easter holiday
marketing campaign delayed by 1 month from mid-January
(based on diff of 2 integrals on previous slide)

impact

impact

Establish urgency by qualitative
matching of cost of delay sketches

time

impact

impact

time

time

time

Intangible – cost of delay may be
significant but is not incurred until much
later; important but not urgent

impact

time

Fixed date – cost of delay goes up
significantly after deadline; Start early
enough & dynamically prioritize to insure
on-time delivery
Standard - cost of delay is shallow but
accelerates before leveling out; provide a
reasonable lead-time expectation

impact

impact

time

Expedite – critical and immediate cost of
delay; can exceed kanban limits (bumps
other work)

time

impact

Cost of Delay has a 2nd Dimension
Working capital

impact

time
Working capital

impact

time

Extinction Level Event – a short delay will
completely deplete the working capital of
the business

Major Capital – the cost of delay is such
that a major initiative or project will be
lost from next year’s portfolio or
additional capital will need to be raised
to fund it
Discretionary Spending – departmental
budgets may be cut as a result or our
business misses its profit forecasts

impact

time

?
time


Intangible – delay causes
embarrassment, loss of political
capital, affects brand
equity, mindshare, customer confidence, etc

3rd Dimension: Shelf-Life Risk
Short
(days, weeks,
months)

Known
Expiry
Date,
Seasonal
(fixed window
of
opportunity)

Medium
(months, quarters,
1-2 years)

Long
(years, decades)


Fashion
Craze
Fad

Shelf-Life Risk
Many

High

High

Schedule Risk

(days, weeks,
months)

Innovation

Number of Options

Short

Known
Expiry
Date,
Seasonal
(fixed window
of
opportunity)

Medium
(months, quarters,
1-2 years)

Long
(years, decades)

Few

Low

Low


Fashion
Craze
Fad

Shelf-Life Risk
Schedule Risk
Low

High

High

Many

(months,
quarters,
1-2 years)

Number of Options

(window of
opportunity)

Medium

Fashion
Craze
Fad

Innovation

Known
Expiry
Date,
Seasonal

Differentiator

(days, weeks,
months)

Spoiler/Follower

Short

Low

Low

Few

Long
(years,
decades)


Low
If we are market leading our
innovations are less time
critical

impact

When should we start something?
If we start too early, we forgo
the option and opportunity to do
something else that may provide
value.
If we start too late we risk
Ideal Start
incurring the cost of delay

time

When we
need it

Here

With a 6 in 7 chance of on-time
delivery, we can always expedite
to insure on-time delivery
85th
percentile
Commitment point


Risk is a multi-dimensional problem
So understanding cost of delay
Yes, however, it isn’t always relevant! Cost of
enables us to know what to pull
delay attaches to a deliverable item. What if
next?
that item is large? Whole projects, minimum
marketable features (MMFs) or minimum viable
products (MVPs) consist of many smaller items.
We need to understand the risks in those
smaller items too, if we are to know how to
schedule work, replenish our system and make
pull decisions wisely


Market Risk of Change

Profits
Market Share
etc

Start
Late

Differentiators
Spoilers
Regulatory
Changes

Cost Reducers

Scheduling

Potentia
l Value

Highly
likely
to
change

Market Risk

Build
(as rapidly as
possible)

Table Stakes
Buy (COTS)
Rent (SaaS)

Highly
unlikely
to change

Start
Early

Product Lifecycle Risk
High

Not well understood
High demand for innovation &
experimentation

Low

Major
Growth
Market

Investment

Growth
Potentia
l

Product Risk

Innovative/New

Cash Cow
Low


Well understood
Low demand for
innovation

Low

High

Risk is a multi-dimensional contextual
problem
These are just useful examples!
We must develop a set of
We can easily envisage other risk dimensions risk
such as technical risk,that work in context for
taxonomies vendor dependency
risk, organizational maturity riskbusiness.
a specific and so forth.
It may be necessary to run a workshop with
stakeholders to explore and expose the real
business risks requiring management


Risk Management


Understanding our tolerance to different
risks
We need to decide what we value as a
business, our strategic
What are our expectations for position & our
predictability, business agility, profitability?
go-to-market strategies
Are our current capabilities aligned with our
expectations?
Have we a clearly stated strategic position and
set of go-to-market strategies?


Matching Cost of Delay Risk to Capability
Business Agility

If we have many fixed date requirements we
need a reasonably strong business agility
capability and a lot of predictability
Standard

Delivery

Predictability

Replenishment

High
for predictability will work. However, our
business will be constantly in a reactive mode
Fixed Date

Lead Time

Where does our
Frequent Short Frequent
Predictability
business currently
Not Applicable Expedite
If we suffer a lot of expedite demand, strong
rank on with business agility without a need
these sliders?
capability

Intangible
Low


Seldom Long

Seldom

Matching Shelf-Life Risk to Capability
Business Agility

Where does our
High
business currently
Short
(days, weeks,
rank on these sliders?

Frequent Short Frequent

Lead Time

Replenishment

Predictability

Are our business strategy and expectations aligned
with our currently observed capabilities?
If we plan to Medium
pursue short shelf-life
opportunities, do we have the agility and
(months,
predictability to pull it off?
quarters,
1-2 years)

Delivery

months)

Long
Low

(years,
decades)

Seldom Long

Kanban system dynamics

Seldom

Matching Market Risk of Change to
Capability Business Agility
Where does our
Less
Highly regulated industries requireFrequent Short Frequent
predictability
in delivery
business currently capability
Differentiators

Lead Time

Predictability

Replenishment

To pursue a strategy of innovation or fast market
following we need a high level of business agility –
fast, frequent
Spoilers delivery

Regulatory
To be innovative or Changes
fast following in a highly
More
regulated industry requires us to be both
predictable and exhibit a high level of business
Cost Reducers
agility

Delivery

rank on these sliders?

Table Stakes
Less


Seldom Long

Seldom

Understanding capability is critical to our
risk management strategy
If you cannot assess your current
delivery capability and align your
strategy and marketing plans
accordingly, then …

You are doomed
before you start!


How much risk do you want to take?
Given our current capabilities, our
desired strategic position and goWe only have capacity to do so much work. How
we allocate that capacity across different risk
to-market strategies, how much risk
dimensions will determine how aggressive we
do you want to take?
are being from a risk management perspective.

The more aggressive we are in allocating
capacity to riskier work items the less likely it
is that the outcome will match our expectations


Hedge Delivery Risk by allocating capacity
in the kanban system DeployEngineering
Ready

2
Expedite

Development
Ongoing

3

Testing

3

Done


1
P1

AB
Fixed
Date

2

E

D

MN

PB
Standard

3

F

G

GY
Intangible

3

I

DE

ment
Ready
∞

Done

Aligning with Strategic Position
or Go-to-Market Strategy
DeployEngineering
Ready

Cost
Reducer
s

3

2

3

Testing

3

Ongoing

Done


niche! Enabling early delivery for narrower
P1
markets but potentially including value
AB
DA
generating differentiating features

E

D

MN

PB
Spoilers

1

F
GY

Differenti
ators

Done

The concept of a minimum viable
∞
product (MVP) will contain the table
Market segmentation can be used to narrow the
stakes for at least given market
necessary table stakes for any 1 market niche
G
2

Table
Stakes

Development

ment
Ready

1


I

DE

Trade off growing market reach against
growing share & profit within Deploya niche
EnginCapacity allocated to Table Stakes will

ment
eering
determine how fast new niches can be Ready
Development
Testing
Ready

Cost
Reducer
s

3

developed.

3

It is important to define a MVP in
∞
Allocate more to Table Stakes to speed market
terms of table stakes and
reach/breadth.
differentiators required to enter a
G
specific market segment
Allocate more to differentiators to grow
P1
2

Table
Stakes

3

Ongoing

Done


market share or AB
profit margins
DA

2

E
Allocate D
more to spoilers to defend market
share MN
PB

Spoilers

1

F
GY

Differenti
ators

Done

1


I

DE

Visualizing Risks on a Kanban
Board


Visualize Risks on the Ticket
Decorators

Title

Typically used
to indicated
technical or
skillset risks

H

Checkboxes…
risk 1
risk 2
risk 3
risk 4

SLA or
Target Date

Letter

req
complete

Color of the
ticket

Business
risk
visualizatio
n
highlighted
in green

Visualize Risks on the Board
Engineering
Ready

2
Expedite

Development
Ongoing

3

Testing

3

Done


1
P1

AB
Fixed
Date

2

E

D

MN

PB
Standard

3

F

G

GY
Intangible

3

I

DE

Deployment
Ready
∞

Done

Abandon Prioritization. Banish Priority
Prioritization is waste!
Prioritization is an exercise to
schedule variable for real business
Priority is a proxya sequence of items at a
risk information.
specific point in time. Only at the
Do not point ofbehind a proxy. Enable better
mask risk commitment can a proper
assessment be made making by
governance and better decision of what to
exposing the business risks under management on
pull next. Filter options based
throughout the workflow
kanban signals. Select from
filtered subset


Part 3
Quantitative Risk Management


2 Real Business Problems
Probabilistic Forecasting requires
me to trust that future system
capability will reflect
If given a choice of systems in which to placethe
business, I would like torecent past choice
(relatively) know the best capability
Lowest price
Fastest delivery
Most predictable delivery


Comparative Assessment
We need a method to monitor the
“trustworthiness” of the system that
makes comparative assessment of
currently observed capability against
We need a comparative assessment
historical observations within the same
system
method to assess comparative

capability across different systems
Must be a leading indicator


Comparative Assessment


Analysis of Cost Distribution
System A Cost($) Per Item
Frequency

10
8
6
4
Frequency

2
0
200

400

600

800 1000 1200 1400 1600 1800 2000 2400 2800 3200 3600 4600 6400 6600 More
Cost Per Item in $

Average cost / item = $2218

Frequency

System B Cost($) Per Item
14
12
10
8
6
4
2
0

Frequency

200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2400 2600 2800 3000 3600 4000 4200 5400 More
Cost Per Item in $

Can you tell which system is better?

Average cost / item = $1723

Analysis of Throughput Distribution
System A Throughput
25

System B Throughput

Mean 1.00 / day

20
15

20

Mean 1.15 / day

15
10

10
5

5

0

0
0

1

2

3

4

More

0

Number of Tickets Per Day

Can you tell which system is better?

2

3

Number of Tickets Per Day

System B Throughput

System A Throughput
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0

1

4.5
4
3.5
3
2.5
2
1.5
1
0.5
0

4

More

Lead Time Distributions
System B

System A Mean 17 days

Mean 12 days

30

14
12
10
8
6
4
2
0

25
20
15
Frequency

10

Frequency

5
0
5

10

15

Lead Time (Days)

20

10
8
6
4
Frequency

45
40
35
30
25
20
15
10
5
0

Frequency

-15

Lead Time Expectation Spread (Days)

More

System B

12

0

30

Lead Time in Days

System A

2

25

-10

-5

0

5

10

15

20 More

Lead Time Expectation Spread (Days)

System B is clearly faster with better due date performance (but are
they processing work of similar complexity & size?)

Comparison
System A

System B

Cost (avg per item)

$2218

$1723

Throughput (avg per day)

1.00

1.15

Lead time (mean days)

17

12

Avg system WIP (items)

17

14

Avg. WIP per State

4.25

2.8

Due Date Performance
(% within expectation)

42%

75%

•
•
•
•
•

System A costs 29% more per item than System B
System B has 15% higher delivery rate than System A
System B is typically 5 days (or 29%) faster than System A
System B delivers 33% more items within expectation
Total WIP is not significantly different in either system


Comparative assessment
• System B has a lower average cost and a
more “normal” distribution of cost
• System B has marginally faster delivery
rate and smoother flow of delivery
• System B has shorter lead times with more
superior due date performance
• Systems A & B have similar amounts of WIP
• System B does appear a better choice but
doubts remain over whether it would
perform as well, if given the same work as
System A.

Liquidity


Where is the best place to place a work
order to best manage risk?
But can we view kanban systems as

Investment bankers know how to answer this
markets for software
question! They prefer to place orders in liquid
markets. In a highly liquid market they have
development?
trust that an order will be fulfilled
accurately, quickly and at the correct price.
Highly liquid markets are markets with a high
level of trust. High liquidity inherently gives us
high confidence in the market.


Liquidity in the housing market
Sellers

$100

Bank

Buyers

Cash
$100


Measuring Liquidity
The more transactions, the more
liquid the market
what is required are well matched
buyers, sellers and access to capital such as
mortgages, bridging loans or cash measured
Market liquidity is buyers
injecting capital into the system, to fund the
transaction volume
transactions .
when these conditions are present transactions
will take place!


as

Adverse Market Conditions
In a market with lots of buyers but few well
matched sellers, inventory will be scarce, few
transactions will occur. When a property comes on
the market it could sell quickly but there will be
anxiety over the correct price. This may delay the
sale or cause the buyer to overpay through fear of
losing the purchase to competitive buyers. In some
markets like England, the seller may refuse to
close the transaction in hope of a higher price
(gazumping).
Lack of liquidity causes a lack of trust in the
system and delays transactions


More Adverse Market Conditions
In a market with lots of sellers but few well
Hence, market grow and few
matched buyers inventory will liquidity can be
transactions will happen.rate of transactions
measured as Uncertainty will
develop over the correctconcluded! trust
price. A lack of
will result in a disparity between asked prices
and offered prices. Additional information may
be sought to establish a fair price. Transactions
will be delayed


So, how would we measure
liquidity?


Measuring Liquidity


Measuring Real Liquidity…

If we recall, liquidity is measured as
transaction volume in the market. So
what are the transactions in a kanban
system?


Pull Transactions in Kanban
Pool
of
Ideas

Engineering
Ready

2

F

Development
Ongoing

3

Done

Testing

3


Deployment
Ready
∞

For work to flow freely in a kanban system, we
must have work available to pull and suitably
matched workers available to pull it. Hence, the
No Pull
act of pulling is the indicator that an item of
Workwork was matched to available workers and
flows through a kanban system when we
have well matched work order or items of WIP
flow happened.
with suitable staff to add valuable new
G
D
knowledge and progress work E completion.
to

I


Done

Variety & Specialization increase WIP
Pool
of
Ideas
∞

K

L

As a
DeployEngin- result, there will be a minimum level of
WIP
ment
eering required to facilitate flow. For systems
Testing
Development
with inherent liquidity problems - lots Ready
of
Ready
4

5 Done
heterogeneity in work types or variance in
Ongoing
4
∞
demand for quality (non-functional
requirements) and|or lots of specialists
workers, non-instant availability problems or
No Pull
J variability in skill and experience of
workers, then the WIP in the system will need
More WIP increases liquidity & freely.
to be larger in order for work to flow
The liquidity measure will not rise until the
G
increase flow!
D
E
WIP rises.

And Cost!

I
F

Pull
Pull


Done

Can you tell which of these systems is more liquid?

Liquidity is measured as derivative of
the rate of pull transactions

To make the measure robust to the
number of states in the kanban
system, the amount of WIP and the
number of workers involved, we
propose the derivative of the rate of
pull transactions as the indicator of
liquidity.


Analysis of Derivative of Pulls

The derivative shows us clearly that System B has smoother flow and
is a more liquid system

Comparative assessment
Assessing the spread of variation in
the derivative of pull transactions
gives us a metric for assessing the
predictability of a kanban system.

A narrow spread in the derivative
shows a smooth flowing (laminar)
system that is likely highly
predictable.
A wider spread implies turbulent or
unpredictable flow implying higher
risk


Trustworthiness

A trustworthy kanban system will
exhibit smooth laminar flow. The
spread in the derivative values will
be narrow.
Such systems are most likely to
offer the most predictable results.


Managing Risk with Liquidity Metrics
Probabilistic forecasting in Kanban
is based on the assumption that the
recent past will reflect the near
future.

We must monitor the derivative of
the rate of pull transactions.
Changes in the rate of pull may
indicate that the recent past, no
longer reflects our current
reality. Hence, probabilistic
forecasts are at risk


Characteristics of Liquid Markets
A liquid financial market would exhibit
several characteristics…
Tightness – bid-ask spread
Immediacy - how quick an order is filled
Breadth - ability to handle large orders
Depth - processing orders at different
prices
Resiliency - ability of the market to swing
back to normal or adjust after a surge in
orders off the market or one large order
that moves the price....


Assessing Liquidity Kanban System
A liquid kanban system would exhibit these
characteristics…
Tightness – spread in derivative of pull
transactions indicating trustworthiness and
likelihood of on-time delivery
Immediacy – shape of lead time distribution
(mode, median, mean, and tail 85%ile, 98%ile)
Breadth – variety of types of work handled
(incl size from single requests to large
projects)
Depth – variety of risks under management
(and depth of taxonomies)
Resiliency - ability of the system to recover
to normal or adjust after a surge in orders
breaching WIP constraints or swarming on
expedite orders…


Analysis of Derivative of Pulls

Some of the derivative
A histogram and run chart work remains to make it
of pull transactions robust clearly the
shows to recirculation of tickets
And…
on the board
liquidity in the kanban system
Experimentation is needed to
This metric is independent of the sample of re-cycling
determine how far When to number
back encountering
tickets(negative
states in the workflowprovideamount ofpull) the
the distribution to or the sufficient WIP
resulting positive pull should
data to indicate current normal
not be counted
operating range for liquidity


Visualizing Liquidity


Liquidity Board Deconstructed
Immediacy – Lead Time SLA
Color of shape represents
age
Tightness – Derivative of
pull transactions
Breadth – Types of worked
pulled (Size)
Depth – Managed Risk
Resilience – Recover to
normal circumstances after
an exceptional period


SLA Not Met
Relatively old

SLA Met
Relatively young

Green arrow pull transaction

Large

High

Med

Med

Smal
l
Low

SLA is affected briefly due
to swings in Breadth, Depth
and Immediacy, but comes
back to normal.

System A – Liquidity Board

•

Immediacy – Lead time SLA is met less than 50% of the time and
work items stay in a work state for a relatively long period of
time

•

Tightness – Inconsistent number of pulls through the workflow

•

Breadth – Little variance in breadth size of items typically small
or medium

•

Depth – Little variance in managed risk items are typically low in
risk

•

Resilience – Once the system has one to two large items come in it
really never recovers


System B – Liquidity Board

•

Immediacy – Lead time SLA is met 80 % of the time and work items
stay in a work state for a relatively short period of time

•

Tightness – Relatively consistent number of pulls through the
workflow

•

Breadth – large variance in breadth; size of items range from
small to large

•

Depth – Large variance in managed risk, items range from low to
high

•

Resilience – Once the system takes on large items and high risk the
SLA suffers, but eventually recovers


Decisions to Route Work

System A should only be given
We should encouragethat is known to be small
work managers in
System A to adoptis not timeand
and practices critical
techniques can in
So what conclusions usedwe System B
draw about how to route work be trusted with a
System B can
We are likely to
within this organization? place new (in size and risk
greater variety
investment in System B as we trust especially
profile) of work and
the managers bettercriticala more
time to run work
liquid system


Summarizing Liquidity


Liquidity of the system should be
considered against observed capability
before placing an order
Some kanban systems may appear
faster and cheaper but carry more
inherent risk as they have poorer
liquidity, handle less variety, are less
resilient (can’t cope with or recover
from burst traffic)
Slightly longer to deliver but with
greater certainty may be preferable
to a system with a lower average lead
time but poorer liquidity & greater
risk


Observed
Capability

Liquidity is a Good Metric
Our measure of liquidity, as pull
transaction volume and the spread of
its derivative, meets the criteria* for a
useful metric…
Liquidity is a global system
Simple
measure.
Self-generating
Relevant
Driving it up should not cause
Leading Indicator
local optimization or undesired
consequences!

* Reinertsen, Managing the Design Factory 1997


Observed
Capability

Relevance of Liquidity as a Measure
Little’s Law

So our plans carry less
buffer for variation
In order to have confidence that our
Narrow spread of forecasts,in leadon
probabilistic variation based
And
time (recent) historical data more
for a fixed WIP means a for the
predictable delivery rate. This is
distribution of lead times, are
turn means greater must monitor the can
Our planning horizons
accurate, we predictability on
delivery date for a given volume as an
derivative of pull transactions
be shorter!
of work and therefore a more
indicator that the risk isn’t changing
accurate price.


Improving Liquidity through Labor Pool
Flexibility
Engineering
Ready

Teams

3

F
Cost
Reducer
s

Spoilers

2

1

3

Development

Testing

3


Steven
Brian

Done

Ongoing

Done

flexibly across rows
on the board to keep
work flowing

G
GY

Differenti
ators

1

3

It’s typical to see splits of
Promotions from
fixed team workers versusjunior
team member to flexible
flexible system workers
Joe
Dworker with
David of between 40-60% an avatar
P1
clearly visualize why a pay
PB
DE
rise is justified. Flexible
Peter
Roughly half the labor
E
Rhonda
workers help manage
Generalist or T-shaped
pool are flexible workers
MN
people who can move
liquidity risk better!
AB
Ongoing

2
Table
Stakes

Team
LeadAnalysis

Joann
Ashok


Junior who will be rotated
through all 4 teams

Conclusions


Kanban enables new powerful approaches to
risk management in knowledge work
Kanban systems enable us to visualize
many dimensions of real business
risks.

Kanban is enabling the
practical with capacity
Hedging risks is possibleapplication of
allocation in the system
real option theory and
related concepts like real
liquidity


Qualitative Approaches are Lean
Qualitative approaches to risk
assessment are fast, cheap and drive
Stop speculating about
consensus

business value and ROI.
There is no crystal ball gazing! Riskrisks
Instead assess real
analysis is not speculative!
and design kanban systems
to manage them!


Quantitative Approaches are also Lean
Quantitative approaches to using
historical data and probabilistic
Stop speculating about
forecasting are viable and cheap and
hence Lean!
future outcomes. Forcast

probabilistically and
to
assess trustworthiness of
forecasts!

There is no crystal ball gazing! Risk
monitor the liquidity
analysis is not speculative!


Don’t Set Yourself Up for Failure

Know your your strategic plan
If current capabilities!

&
marketing objectives are
Lead time distributions &
not aligned with your
replenishment and delivery cadence
define business agility!
current capabilities, you
many be doomed before you
start!


Kanban & Qualitative Risk Assessment
are powerful in combination
Kanban systems address variability in,
and focus attention on improving,
Fullyflow!
exploit Kanban-enabled

business agility to delivery
Improved predictability & business
better business outcomes
agility from Kanban is only valuable
if through qualitative &
exploited
quantitative risk management


Thank you!

About

David Anderson is a thought
leader in managing effective
software teams. He leads a
consulting, training and
publishing and event planning
business dedicated to
developing, promoting and
implementing sustainable
evolutionary approaches for
management of knowledge
workers.
He has 30 years experience in the high technology industry
starting with computer games in the early 1980’s. He has led
software teams delivering superior productivity and
quality using innovative agile methods at large companies
such as Sprint and Motorola.
David is the pioneer of the Kanban Method an agile and
evolutionary approach to change. His latest book is
published in June 2012, Lessons in Agile Management – On the

Road to Kanban.

David is a founder of the Lean Kanban University, a business
dedicated to assuring quality of training in Lean and Kanban
for knowledge workers throughout the world.


About

Raymond Keating has 20 years’
experience in the financial and
technology industry developing
and managing trading systems
for major financial institutions
such as J.P. Morgan, Republic
National Bank, HSBC, NYMEX and
the CME Group. Ray is an
Accredited Kanban Trainer
through the LKU.
Currently Raymond is Director of Software Engineering at
the CME Group. Functioning as the development manager for
the ClearPort trading application and change agent for the
group he has evolved the processes and policies by
applying the core practices of Kanban. Recently Raymond
has been researching applying the characteristics of
market liquidity to a Kanban system.


Acknowledgements

Donald Reinertsen directly influenced the adoption of virtual
kanban systems and the assessment of cost of delay & shelf-life as
criteria for scheduling work into a kanban system.
Chris Matts & Olav Maassen strongly influenced the concept of
options & commitments and the upstream min-max limits is based on
an example first presented by Patrick Steyaert.
We’d like to thank Andrew Milne for the animation of liquidity
visualization and CME Group for their collaboration and access to
data to demonstrate the quantitative theories presented here

David J Anderson
& Associates, Inc.


Appendix



Fixed Date

Intangible

Standard

Expedite

Example Distributions

Key Note - Lean Kanban North America 2013 - Beyond Kanban

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Key Note - Lean Kanban North America 2013 - Beyond Kanban

Ähnlich wie Key Note - Lean Kanban North America 2013 - Beyond Kanban (20)

Mehr von David Anderson

Mehr von David Anderson (10)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Key Note - Lean Kanban North America 2013 - Beyond Kanban

Hinweis der Redaktion