Lean Kanban Netherlands 2012 - Lean Risk Management

Lean Risk Management
Options, Liquidity & Hedging
Risk using Kanban Systems

How Kanban is enabling a new
approach to risk
management in knowledge
work
Lean Kanban Netherlands,
Utrecht, October 2012

dja@djaa.com, @agilemanager

Making Promises with Kanban
(and some often poorly understood fundamentals)


Commitment in Kanban
Pool
of
Ideas

Engineering
Ready

Ongoing

2

Testing

Development

3

Done

3

Verification Acceptance

Deployment
Ready
∞

Pull

F

D

G

P1

E

PB

I

GY

DE

MN
AB

We are committing to getting
started with a probabilistic
expectation of delivery time

1st Commitment point

Done

2nd Phase Delivery Commitment
Pool
of
Ideas

Engineering
Ready

2

Testing

Development
Ongoing

3

Done

F

3


D
PB

∞

MN

G
DE

Deployment
Ready

P1

E
AB

I
GY

We are now committing to a
specific deployment and
delivery date

2nd Commitment point

Done

Defining Lead & Cycle Time
Pool
of
Ideas

Engineering
Ready

2

Pull

Deploy-

The clock starts ticking when
ment
Testing
we
Development accept the customers
Ready
3
3 order, not when it is placed!

Ongoing

Done

∞ queue.

Cycle time is an ambiguous term. It
D
This provides theP1correctmust be qualified, for
example,
G result for Little’s Law and Development Cycle Time

E

I

∞

Until then customer orders are
merely available options
Lead time ends when the item
reaches the first

F


Done

PB
visualization on a Cumulative
End-to-end Cycle Time = Time from 1st
GY
DE
MN
Flow Diagram
AB
commitment to delivery

Lead Time

Cycle Time
Cycle Time

Little’s Law

=

Delivery Rate

Pool
of
Ideas

WIP
Lead Time

Avg. Lead Time
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


Deployment
Ready
∞

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

E

PB
GY

DE

Waiting Working

x 100%

Lead Time

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

I

Done

MN
AB

Waiting

Working Waiting

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


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!
The workexpectation of
SLA is of two types:
Change Requests (new
105 and Production
features);days with 98 %
Defects

Mean of 31
days

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 Modal
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

Risks & Qualitative Assessment


Key Risk to Manage is What to Pull Next
Pool
of
Ideas

Engineering
Ready

4

∞

Development
Ongoing

3

Done

Deployment
Ready

Testing

3


∞

Replenishing the system is an act of commitment
– selecting items for delivery – for conversion
from options into real value.
J

K
L

G

Pull Selection is choosing from immediate
options – ideally have 4 options, which one item
I dynamic selection of the
Pull
D most immediateErisk attached to it
with the
should I choose?

I
System
Replenishment

F

Pull

Pull
Selection


Done

Lean Risk Management 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 Management!

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


impact

impact

Establish cost of delay (or urgency) by
qualitative matching

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 other kanban limit
(bumps other work)

time


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


Classes of Service Manage Cost of Delay
Risk
DeployEngineering
Development
Ready
Different distributions for

3

Ongoing
classes of

Testing

3

different
2
increases the level of trust that
an item will be delivered in a
Expedite 1
timely manner, demonstrating
that cost of delay is a risk under
management
AB
Fixed
Date

2

Done
service Verification Acceptance

P1

E

D

MN

PB
Standard

3

F

G

GY
Intangible

1

I

DE

ment
Ready
∞

Done

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


Market Risk of Change

Market Risk

Potentia
l Value
Profits
Market Share
etc

Start
Late

Differentiators
Spoilers
Regulatory
Changes

Cost Reducers

Scheduling

Highly
likely
to
change

Table Stakes
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 risk and so forth.
a specific business.

It may be necessary to run a workshop with
stakeholders to explore and expose the real
business risks requiring management


A middle-ground in effective Risk
Management

Qualitative Taxonomies
2 -> 6 categories
Cheap
Fast
We can easily envisage other risk dimensions
Accurate
such as technical risk, vendor dependency
Consensus
risk, organizational maturity risk and so forth.
Managed Risk
It may be necessary to run a workshop with
stakeholders to explore and expose the real
business risks requiring management

Homogenous
Cheap
Fast
High Risk


Heterogeneous
Expensive
Time Consuming
Fake Precision?
May still be
High Risk

Visualize Risks to provide Scheduling
Information
Outside:
Start Early

Market Risk
Items with the same shape carry the same risks
and should be scheduled into the kanban system
TS
at approximately the same time.
CR
It is also wise to hedge risk by
Do not
Tech Risk
Lifecycle
New
allocating prioritize items. From a whichever ones
capacityprofile pick group for
in the system of items
Spoilrisk
with the same
items of differentMidprefer most Start Late
risk profiles.Inside:
you like or
Unknown Soln
Diff Cow
Known but not us
Done it before
Commodity
Intangible
Disc
Std
Maj. Cap.

ELE
Delay Impact

FD

Expedite

Risk profile
for a work
item or
deliverable
Cost of Delay

Hedging


Hedging Delivery Risk with Capacity
Allocation
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

2
Table
Stakes

3

Cost
Reducer
s

2

Development
Ongoing

3

Testing

3

Done


E

D

MN

1

F
GY

Differenti
ators

∞

Market segmentation can be used to narrow the
necessary table stakes for any given market
G
niche! Enabling early delivery for narrower
P1
markets but potentially including value
AB
DA
generating differentiating features
PB

Spoilers

ment
Ready

1


I

DE

Done

Hedging Risk in a Portfolio Kanban
Horizational position shows percentage complete
Allocation of personnel
Complete
Total = 100%
0%

Cash Cows
10% budget

Innovative/New
30% budget

B

A

Growth Markets
60% budget

D

C

K

E

G
F


Complete
100%

Projects-in-progress

Color may indicate cost of
delay (or other risk)

H

Options


Some Options Get Discarded
Pool
of
Ideas

Engineering
Ready

Ongoing

2

Testing

Development

3

3

Done


Deployment
Ready
∞

Pull

F

D

G

P1

The discard rate can be as
Emuch as 50%

PB
GY

DE

Reject
Discarded

I

MN
AB
have value

Options
because the
future is uncertain
0% discard rate implies there
is no uncertainty about the
future

Done

Bottleneck should always be downstream
of the commitment point
Pool
Enginof
Ideas

eering
Ready

Ongoing

2

Pull

F

Analysis

3

Done

Development

Testing

3


Ongoing

Done

Bottleneck workers should never be asked to
work on something that is optional and may be
discarded. This includes any risk analysis (or
estimation in legacy processes) that may be
D
P1
required to assess viability of an option

G

E

PB
GY

DE

Reject

MN
AB

Discarded

I
Commitment point

Bottleneck should be here

3

Competing pressure of Last Responsible
Moment versus Upstream Bottleneck
Pool
of
Ideas

EnginIn domains with Development
high uncertainty the
eering
Testing
Analysis
Ready
3
3

bottleneck should be Done Verification Acceptance
3 deliberately
Done
Ongoing
late in the2workflow. We should be
prepared to discard options very
Keeping the bottleneck early in the workflow
means all downstream functions have slack
late.
Ongoing

F

capacity. Reduces our need to manage WIP and
reduces negative effects of variability in demand
D
P1

Consider Lean Startup?...

G

PB
GY

E

Where is the MN
bottleneck?

DE

AB

Last Responsible Moment
Commitment point

Bottleneck early in workflow

impact

The Optimal Exercise Point
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

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


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

Liquidity is measured as volume of
pull transactions

Thus, I am proposing that system
liquidity be measured as the volume
of pull transactions happening in a
given time period.


Normalizing Liquidity Measures
To normalize this figure across
multiple systems, we could divide it
by the number of workers
involved, or the (fixed) cost of
running each system over a time
period. This would give us
pull transactions/person
Or,
pull transactions/€


Pull Transactions / Person

Greater values for pull transaction
volume serve to show us the most
trustworthy system.
They represent the system most
likely to offer the most predictable
results.


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


Characteristics of a Liquid Kanban
Market
A liquid kanban system would exhibit these
characteristics…
Tightness* – variance between customer
expectations and probability of meeting it
within current lead time capability (Due Date
Performance???)
Immediacy – flow efficiency or waiting time
until pull**
Breadth – variety of types of work handled
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…
* Is this even relevant without a market maker?
** Some work still required to determine
whether time blocked should be included or not


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 per person or unit
of currency in a time period, meets
Donald Reinertsen’s criteria for a
useful global
Liquidity is ametric… system
measure.
Simple
Self-generatingup should not cause
Driving it
Relevant optimization or undesired
local
Leading Indicator
consequences!


Observed
Capability

Relevance of Liquidity as a Measure
Little’s Law

So our plans carry less
buffer for variation
Narrow spread of variation in lead
And
time for a fixed WIP means a more
predictable delivery rate. This is
Our planning horizons
turn means greater predictability on
delivery date for a given volume
be shorter!
of work and therefore a more
accurate price.


can

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


Lean Risk Management is Pragmatic
Qualitative approaches to risk
assessment are fast, cheap and drive
consensus
Stop speculating about

business value and ROI.

There is no crystal ball gazing! Risk
Instead assess real risks
analysis is not speculative!

and design kanban systems
to manage them!


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.


Acknowledgements

Raymond Keating of CME Group in New Jersey has been instrumental
as a collaborator on the ideas in this presentation.
Real liquidity emerged as an idea from discussions on real options
theory with Chris Matts, Olav Maassen, Mike Burrows and Julian
Everett over a period totaling greater than six years.
Some final refinement of the concepts came about as a consequence
of a conversation with Jon Jagger in October 2012.

David J Anderson
& Associates, Inc.


Appendix


Identifying Buffers
Pool
of
Ideas

Engineering
Ready

Ongoing

2

F

GY

3

Done

verification Acceptance

I am a buffer!
P1

PB

I

3

D

G

Testing

Development

Deployment
Ready

DE

The clue isis in my name “…
The clue in my name – –
E
Ready”
“… Ready”
MN
AB

I am buffering non-instant
availability or activity with a
availability or an activity with
acyclical cadence
cyclical cadence


∞

Done

Infinite Queues Decouple Systems
Pool
Enginof
eering
The infinite queue Development
decouples
Ideas
Ready

the systems. The deployment
3 Done
Ongoing
system uses batches and is
2
separate from the kanban
system

F
The 2nd commitment is
actually a commitment for
PB
the downstream deployment
system
DE

Deployment
Ready

Testing

3


D

∞

MN

G

P1

E
AB

The Kanban System gives us
confidence to make that
I
downstream commitment
GY

2nd Commitment point

Done

Change Requests

The psychology of a probabilistic approach
can be challenging…

I don’t want to take the risk of
being longer than 60 days. Mean
I need
a precise estimate of when it
50 days
will be delivered!

98% at
150 days
85% at
60 days


A lack of organizational social capital…
A lack of organizational social capital may
prevent trust in the kanban system from
There isemerging. The result is a degeneration to a
a trust in individual people rather than
the system. Individuals are held system.
deterministic accountable via
their commitments.
Everything must have an estimate. Plans are
Deterministic planning means a high likelihood
drawn deterministically. Overhead and rework
of incurred as things
(of plans) isbroken promises. change. Early and
specific commitments are requested
People take the blame!


…replace trust with comfort & reassurance

Deterministic planning provides a level of
When people take the blame, replacing the
comfort. Deterministic plans seem accurate and
people provides a level of comfort that
plausible.
remedial action has been taken.
When promises are broken it further
The organization is caughtsocial capital in the
undermines the in a vicious cycle of
distrust, individual
organization.
commitment, disappointment, blame and
repercussions!


Liquidity in the housing market
Sellers


$100

Bank

Buyers

Fixed Date

Intangible

Standard

Expedite

Example Distributions


Lean Kanban Netherlands 2012 - Lean Risk Management

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Lean Kanban Netherlands 2012 - Lean Risk Management

Ähnlich wie Lean Kanban Netherlands 2012 - Lean Risk Management (20)

Mehr von David Anderson

Mehr von David Anderson (17)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Lean Kanban Netherlands 2012 - Lean Risk Management

Hinweis der Redaktion