Key Note - Software Executive Summit - Better predictability with kanban

Delivering Better Predictability,
Business Agility & Governance
with Kanban

Executives demand
improved agility without
sacrificing predictability &
governance
Software Executive Summit,
Seattle, November 2012

dja@djaa.com, @agilemanager

Background


Microsoft 2004 - the XIT Story
Change requests
PTCs
Product
Managers

PM
Testers
RequestsDevelopers
for estimates or analysis of
future work are often
‚invisible‛, have an unpredictable
arrival rate & are given priority. &
Emergency work is unplanned User Acceptance
receives highest priority. Arrival rate
& volume are unpredictable.
PTCs? What did that acronym mean?
Items that did not require coding!
Effect is hugely disruptive!
Why were they treated as
emergencies?

Prioritized
Backlog

Waiting for
Test

Predictability, Agility & Governance
So how were they doing on our
PTCs
measures of predictability, agility &
governance?
Product
Testers
Developers
Managers
On-time delivery was 0%. There was a 100%
chance of interruption to estimate future
work.
User Acceptance
Planning & prioritization were conducted
monthly. Fastest response from receipt to
deployment was around 6 weeks.
But everything had a business case and was
prioritized by ROI!
So the drive for good governance was
Prioritized
destroying predictability and agility!
Waiting for
Backlog
Test

What Were the Issues?
So what issues affected the outcome?
PTCs were governance policies so
Why
disruptive?
Testers
Developers

Product
Managers
Product managers demanded fast response on
estimates to facilitate future planning and
provide fast feedback to business owners. User Acceptance
Entire backlog was planned & commitments
made early. 90% of the backlog was re-planned
each month.
Expedite policy for PTCs was folklore – no one
could explain why
Process Improvement Conclusion
Controlling unplanned, disruptive
Prioritized
demand would improve
Waiting for
Backlog
predictability!
Test

A virtual kanban system was chosen
Backlog

Engineering
Ready

5
Change
Requests

Pull

F F
F
F F
F
F

PTCs

G

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

It’s important to realize the process
for software development did not
B
Pull change. The kanban system is an
overlay on the existing process. It
G
C
Pull
changes scheduling and prioritization
only

F

D

PTCs are permitted to break the
kanban limit
*Blocked to service PTC


*

I

Deployment
Ready
∞

CRs
50

240%
improvement
in delivery
rate

The Results Backlog depleted.
Serving at rate of
demand

30

Average
Time to Resolve

10

Time (in quarters)
125

90% drop in end-toend cycle time*

75
25

* Includes queuing time prior to selection

Time (in quarters)

Understanding Kanban Systems


Kanban are virtual!
Backlog

Engineering
Ready

5

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

Change
Requests

Deployment
Ready
∞

B
Pull
These are the virtual kanban
F J
G
C
F
Pull
Boards are not required to do
F F
Kanban!
F
I
F
The board D a visualization of the
is
F
*
The first system used database
workflow process, the work-intriggers to signal pull. There was no
progress and the (virtual) kanban
PTCs
board!

Pull

I


Commitment is deferred
Backlog

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

E

Wish to avoid discard after commitment

PTCs

Commitment point


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

I

Deployment
Ready
∞

Discard rates are often high
Backlog

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
∞

Specific delivery commitment may be
deferred even later
DeployEnginBacklog

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*

Replenishment Cadence
Backlog

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

Engineering
Ready

Pull

F F
F
F F
F
F

Testing

UAT

3

5

3

∞

Ongoing

Done

Frequent deployment is
more agile.

5
Change
Requests

Development

Test
Ready

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

Defining Lead Time
Backlog

Engineering
Ready

5

The clock starts ticking when
Test
UAT
we Ready
customers
Development accept theTesting
5
∞
3 order, not when it3is placed!

Ongoing

Done

Until then customer orders are
merely available options
Lead time (through

Change
Requests

the kanban system)
ends when the item
reaches the first

Pull

F F
F
F F
F
F

Deployment
Ready
∞

D

∞ queue.

I

G

E

This provides the
correct result for
Little’s Law and
visualization on a
Cumulative Flow
Diagram

Lead Time

PTCs

Discarded

I

Little’s Law
WIP

=

Delivery Rate

Lead Time

Backlog
Mean Lead Time
WIP


Ready
To
Deploy

Mean Delivery Rate

Improving Agility


Factors Affecting Agility
Kanban decouples replenishment
from lead time & delivery enabling
The businesstailoring of the process to the
agility of the system is determined
by the replenishment of the business domain
dynamics cadence, the delivery
cadence and the lead time (or end-to-end cycle
time) through the system.


Benefits of Limiting WIP
Backlog

Engineering
Ready

5
Change
Requests

Pull

F F
F
F F
F
F

G

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

Limiting WIP reduces multi-tasking.
Shortens lead time. Focuses
E
organization on impediment removal
D
#*
Bug
and limits due date performance
degradation from poor quality &
rework

Lead
Blocked!

Time

PTCs
*Specialist

test environment
unavailable
Blocked!

Discarded

I

I

Defect found requiring coding
fix


Deployment
Ready
∞

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
Backlog

Engineering
Ready

Ongoing

2
Change
Requests

Development

5

3

Done

Testing

3

Verification Acceptance

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

Flow Efficiency

Flow efficiency measures the
percentage of total lead time
Pool is Engin- actually adding
that spent
of
eering
value (or knowledge) versus
Development
Ideas
Ready
waiting
3
Ongoing

2

Done

Testing

3


Deployment
Ready
∞

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

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

E

PB

I

GY

DE

Waiting Working

MN
AB

Waiting

Working Waiting

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

Done

x 100%

Benefits of Reducing Lead Time
Backlog

Engineering
Ready

5
Change
Requests

Pull

F F
F
F F
F
F

PTCs

Discarded

Development

Test
Ready

Testing

UAT

3

5

3

∞

Ongoing

Done

Short lead times enable later
commitment, reduce likelihood of
post-commitmentE
discard or rework
D
Bug
due to perishable nature of
Bug
information and improve quality as
G
Bug
defect insertion rates fall nonlinearly reduces chance of
Short lead timewith reduced lead time

discard
Defect insertion rate increases
non-linearly with long lead
times and low flow efficiency.

I
Defect fix times increase nonlinearly with delay time from
I
discovery to fix


Deployment
Ready
∞

Flow
Efficiency (%)

More Results (from 2005)
Flow efficiency
improved from
8% to 92%

75
45

Due Date
Performance

15

These improvements were minimally
intrusive, met with little to no resistance
(though some managerial derision) and
cost almost nothing!

75

If Time (in quarters) well,
it works this
perhaps we should try this
DPP improved
again?!!
almost instantly

45
15

* Measured from point of commitment

from 0% to 98%
against lead time
SLA*

Time (in quarters)

Ability to handle variety and heterogeneity
of risks improves business performance
Kanban enables us to build a trusted
The kanban system explicitly exposes the
delivery capability. Agility and
business risks in terms of types of demand,
predictability are tuned to the
quantity & rate of demand. It helps us to
understandinherent risks in the business
the costs & benefits of frequent
interaction with upstream & downstream
domain!

functions. And it gives us a temporary and
quantitative understanding of our capability to
deliver against demand


Better Governance


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. Committing to the
cost to convert from options into real value.
J

K
L

G

Pull Selection is choosing from immediate
options – an act of dynamic prioritization of the
I have 4 options, which one
Pull
D most immediate risk attached to it
E
item with the
should I choose?

I
System
Replenishment

F

Pull

Pull
Selection

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


impact

impact

Cost of Delay is a critical business risk

impact

impact

time

Expedite – critical and immediate cost of
delay; can exceed other kanban limit
Qualitative approaches to risk
(bumps other work)
management using taxonomies of 2 to 6
time
categories for each dimension of risk goes up
Fixed date – cost of delay have
been shown to fast, cheap & effective in
significantly after deadline; Start early
comparison to quantitative methods that to insure
enough & dynamically prioritize
often involve speculation and false
on-time delivery
time
precision
Standard - cost of delay is shallow but
accelerates before leveling out; provide a
reasonable lead-time expectation

impact

impact

time

time

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

impact

time

time

Implementing Classes of Service
Engineering
Ready

Development
Ongoing

Expedite

Fixed
Date

Standard

3

Done

2

E

D

3

F

1

I

3


Different distributions for
2
different classes of service
increases the level of trust that
1
an item will be delivered in a
timely manner, demonstrating
P1
that cost of delay is a risk under
management

G
Intangible

Testing

Deployment
Ready
∞

Done

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


Hedge Delivery Risk by spreading capacity
across items of differing urgency
Engineering
Ready

2
Expedite

Ongoing

2

3

Done

Testing

3


∞

1

Fixed
Date

Development

Deployment
Ready

Standard

Uncertainty in demand or
E
arrival rate of urgent &
critical items is offset with
capacity for items that are
easily delayed
F

D

3

G
Intangible

3

I

Done

Cost of Delay attaches to a deliverable
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


Make a long term plan to build
platform replacement
Device Management Ike II Cumulative Flow

2008

30
-M
ar

23
-M
ar

5x

9M
ar

2M
ar

eb
24
-F

eb

2006

17
-F

10
-F

Slope in middle
3.5x - 5x slope
at ends

16
-M
ar

240
220
200
180
160
140
120
100
80
60
40
20
0

eb

Features

Required throughput (velocity)

During the middle 60% of the project schedule we
Time
need Throughput (velocity) to average 220 features
Inventory Started Designed Coded Complete
per month


Little’s Law

Determines
staffing level

Calculated based on
known lead time
capability & required
PlandeliveryChanging the WIP limit without
based onrate
currently observed
maintaining the staffing level
capability and current working
ratio assume process
practices. Do not represents a change to the
way of working. It is a change to
improvements.
the process and will produce a
Delivery Rateto reduce undesirable‘common
change in the observed
If changing WIP
cause’ capability new
effects (e.g. multitasking), get of the system
Lead Time
sample data (perform a spike) to
observe the new capability
From observed
capability
Target
Treat as a fixed
to
variable
achieve plan

=


WIP

Using Little’s Law

Determines
staffing level

Calculated based on
known lead time
capability & required
At this point perhaps just a little
delivery rate
black magic and experience may
be required.
If our current working

WIP = 22

practices/process exhibited an
Rounding 22 up to 25 would
average WIP of 1 item per person then
55/week 25 people organized infor 5 teams
we require conveniently provide 5
with to complete 5 items each
teams of 5 peoplea WIP limit of the
0.4 weeks
project on-time

=

From observed
capability
Target
to
achieve plan


Treat as a fixed
variable

1 lane per team


WIP in this area
should be 25
items*
*photo taken
early in the
project before it
was fully
staffed/loaded
Lead time

Median lead time
target is 2 days
Alert managers if
beyond 5 days


Conclusions


Kanban systems control variability that
affect predictability
Kanban systems defer commitments is
Committing early
improving quality of decision making
comforting but can lead to
and reducing unnecessary work and
disappointment later.
rework.

Predictability is improved!

Kanban builds trust
enabling deferred
commitment


Kanban enables improved agility
Replenishment & delivery cadences
are de-coupled and can be tuned to
information arrival and overhead of
the transaction.

Industries such as media
Lead time can be independent of
require the decoupled
replenishment & delivery cadence!
dynamics of kanban to react
to unfolding events


Kanban Improves Governance
Visualization of the kanban system
and explicit declaration of policies
improves transparency on risk
Kanban systems can
management

be
designed to align directly
There is no crystal ball gazing! Risk & gowith strategic plans
analysis is not speculative!
to-market strategies


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 published
in June 2012 is, Lessons in Agile Management – On the Road to

Kanban.

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


Acknowledgements

A virtual kanban system was first used with an offshore team within
Microsoft’s IT department in 2004/2005. The Kanban Method as it is
known today emerged at Corbis 2006/2007.
Adoption of cumulative flow diagrams, Little’s Law, virtual kanban
systems & cost of delay were heavily influenced by Donald
Reinertsen.

Major contributors to the material in this presentation include
Daniel Vacanti, Jim Benson, Corey Ladas, Janice Linden-Reed, Troy
Magennis, Chris Matts, Olav Maassen and Julian Everett

David J Anderson
& Associates, Inc.


Appendix


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

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

?
time



Fixed Date

Intangible

Standard

Expedite

Example Distributions

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

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

Market Risk of Change

Profits
Market Share
etc

Start
Late

Differentiators
Spoilers
Regulatory
Changes

Cost Reducers

Scheduling

Potentia
l Value

Market Risk

Highly
likely
to
change

Table Stakes
Highly
unlikely
to change

Start
Early

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

2
Table
Stakes

3

Cost
Reducer
s

2

Spoilers

Ongoing

3

Done

Testing

3


∞

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

E

D

1

Differenti
ators

Development

ment
Ready

1


F

I

Done

Product Lifecycle Risk
High

Not well understood
High demand for innovation &
experimentation

Low

Profit
Margin

Major
Growth
Market

Investment

Product Risk

Innovative/New

Cash Cow
Low

Well understood
Low demand for
innovation


Low

High

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

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


Key Note - Software Executive Summit - Better predictability with kanban

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Key Note - Software Executive Summit - Better predictability with kanban

Similar a Key Note - Software Executive Summit - Better predictability with kanban (20)

Más de David Anderson

Más de David Anderson (14)

Último

Último (20)

Key Note - Software Executive Summit - Better predictability with kanban