Key Note - Path to Agility 2013 - Kanban - the alternative path to agility

Kanban
An Alternative Path to Agility

What is Kanban?
How do you implement it?
What are the benefits?
Path to Agility
Columbus, Ohio 2013

dja@djaa.com, @djaa_dja

The Meaning of Agile


What Agile Methods Seek to Achieve
Agile methods ask us
to…
Agile methods ask us
Enable aMake trust (yet with
Let’s not high to… culture
boreProgress
you
Create slide showing &
again) with craftsmanship
a Feedback Loops
imperfect information
Create a work-in-progress
enable a capability to
Treat
The trust dividend eliminates adapt
the Manifesto!
work ethic liability
bureaucracy & encourages
as Reworking & course correcting
if it were a
collaborative working & use of this was
Withas new Agile methods tacit is
1st gen than an asset
rather information arrives
knowledge
limited to adapting to changing
Encourage high quality, well & faster
better risk management
requirements or “perfect”
engineered code that is for scope
than delaying easily
Knowledge work as new
adapted (refactored)is perishable.
information
Focus on finishing things quickly
information arrives and requires
before they go stale
very little rework due to
errors


The Kanban Method – an
alternative path to agility!


Kanban Method
A management & cultural approach to
improvement

View creative knowledge work as a set
of services
Encourages a management focus on
demand, business risks and capability of
each service to supply against that
demand

The Kanban Method is not…
A project management or software
development lifecycle process

Nor, does it encourage a processcentric approach to improvement!


Don’t do this!...

Management

Imposes

Designs
Or
Defines

Process

Workers


Follow

Process
Coaches

Kanban Method
Uses visualization of invisible work and
virtual kanban systems

Installs evolutionary “DNA” in your
organization
Enables adaptability in your business
processes to respond successfully to
changes in your business environment


Kanban Method
• “Kanbanize” your existing process
• Provoke existing processes to change and
service delivery to improve

• Each workflow will evolve a uniquely
tailored process solution, “fitter” for its
context
• Customer & employee satisfaction will
improve

6 Practices for Evolutionary DNA
The Generalized Version
Visualize
Limit Work-in-progress
Manage Flow
Make Policies Explicit
Implement Feedback Loops
Improve Collaboratively, Evolve
Experimentally
(using models & the scientific method)


What is a kanban system?


A Kanban Systems consists of
“kanban” signal cards in
circulation


Using a virtual kanban system


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 kanban
PTCs
board!

Pull

I


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
∞

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

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

Identifying Buffers
Pool
of
Ideas

Engineering
Ready

Ongoing

2

F

GY


Done

verification Acceptance

P1

PB

I

3

3

I am a buffer!

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

Visualizing Pull Signals
Pool
of
Ideas

Engineering
Ready

Ongoing

2

F

D

G
GY


3

Done

3
verification Acceptance

Done

∞

I indicate “pullable”

P1

E

I am not a separate queue

PB

I

Testing

Development

Deployment
Ready

DE

MN
AB
The WIP

limit for development
applies to on-going or
completed “pullable” work

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

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


Metrics for Kanban Systems
Cumulative flow integrates
demand, WIP, approx. avg. lead time and
delivery rate capabilities
Lead time histograms show us actual
lead time capability

Flow efficiency, value versus failure
demand (rework), initial quality, and
impact of blocking issues are also
useful

Implementing a Virtual Kanban System
Do not copy an existing (virtual) kanban
system!

Each system must be designed from 1st
principles using the system thinking
approach to implementing kanban
A study of demand including business
risks & capability is essential to design
an appropriate (virtual) kanban system
for any given knowledge work service

Reminder…
The Kanban Method is not….
A project management or software
development lifecycle process
Nor, does it encourage a processcentric approach to improvement!
You must “kanbanize” your existing
processes and workflows!

Kanban Kata


Feedback Loops
The Kanban Kata
Operations
Review

Improvement
Kata

Standup
Meeting


Standup Meeting

Disciplined conduct
and acts of leadership
lead to improvement
opportunities
Improvement
discussions & process
evolution happen at

after meetings


Improvement Kata

A mentor-mentee relationship
Usually (but not always) between a superior and a sub-ordinate
A focused discussion about system capability
Definition of target conditions or desired outcomes
Agreement upon counter-measures – actions taken to improve
capability – resulting in process evolution


Operations Review

Monthly meeting
Disciplined review of
demand and capability
for each kanban system
Provides system of
systems view and
understanding
Kanban system design
changes & process
evolution suggested by
attendees

6 Practices for Evolutionary DNA
The More Specific Version
Visualize work, workflow & business
risks
(using large physical or electronic boards in communal
spaces)

Implement Virtual Kanban Systems
Manage Flow
Make Policies Explicit
Implement Kanban Kata
Educate your workforce to enable
collaborative evolution of policies & ways of
working


Scaling out across an
organization


Treat each service separately
Demand

Observed
Capability

Demand

Observed
Capability

Demand

Observed
Capability


Some systems have dependencies on
others
Demand

Observed
Capability

Demand

Observed
Capability

Demand

Observed
Capability


Organizational Improvements Emerge


Scaling Kanban
Each Kanban System is designed from
first principles around a specific
service
Scale out in a service-oriented fashion
Do not attempt to design a grand
solution at enterprise scale
The Kanban Kata are essential!
Allow a better system of systems to
emerge over time. Let evolution work!

Scaling up and down
(big projects, portfolios & personal work)


Summary of Benefits


Collaboration Benefits
Shared language for improved
collaboration
Shared understanding of dynamics of
flow
Emotional engagement through
visualization and tactile nature of boards
Greater empowerment (without loss of
control)

Tangible Business Benefits
Improved predictability of lead time and
delivery rate
Reduced rework

Improved risk management
Improved agility
Improved governance


Organizational Benefits
Improved trust and organizational social
capital
Improved organizational maturity

Emergence of systems thinking
Management focused on system capability
through policy definition
Organizational Adaptability
(to shifts in demand and business risks under management)

Change Management Benefits
Significantly reduced resistance to change
Processes uniquely tailored to business
environment and risk under management

Evolutionary changes reduce impact
during change and lower risk of failure
Change led from the middle and enacted
by the workforce. Reduced need for
coaching and process specialists

Kanban Improves Agility
• Lead times gradually reduce
• Predictability of delivery gradually improves
• Organizational social capital improves
• Governance, risk management are improved

• Empowerment without loss of control
• Improves are often dramatic!
• 700% increase in delivery rate at BBC
• On-time delivery often greater than 90%
• Delivery times often reduced by up to 90%


Learn More

http://leankanbanuniversity.com
• For best results, work with an accredited trainer (AKT) or
credentialed Kanban Coaching Professional (KCP)

http://www.leankanban.com
• Part of a global conference series promoting Kanban
and related concepts for improved business performance

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

Hakan Forss of Avega Group in Stockholm has been instrumental in
defining the Kanban Kata and evangelizing its importance as part of a
Kaizen culture.
Real options & the optimal exercise point as an improvement over
“last responsible moment” emerged from discussions with Chris
Matts, Olav Maassen and Julian Everett around 2009.

The inherent need for evolutionary capability that enables
organizational adaptation was inspired by the work of Dave
Snowden.

David J Anderson
& Associates, Inc.


Appendix



Fixed Date

Intangible

Standard

Expedite

Example Distributions

Key Note - Path to Agility 2013 - Kanban - the alternative path to agility

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Key Note - Path to Agility 2013 - Kanban - the alternative path to agility

Similar to Key Note - Path to Agility 2013 - Kanban - the alternative path to agility (20)

More from David Anderson

More from David Anderson (20)

Recently uploaded

Recently uploaded (20)

Key Note - Path to Agility 2013 - Kanban - the alternative path to agility