patterns of kanban maturity

Copyright Lean Kanban [email protected] @lki_dja

Patterns of KanbanAppropriate designs for your level of organizational maturity

Presenter:David J. Anderson

Lean Kanban North America

San DiegoMay 2016


The Kanban Method


The Kanban Method

Simple Underlying Principles

1. Intangible Goods (professional services) businesses can be managed like physical, tangible goods businesses

2. Represent intangible goods with tangible artifacts

3. Make invisible work & workflows visible4. Control & limit inventory of intangible goods


The Kanban Method

Service Delivery Principles

1. Understand and focus on your customers’ needs and expectations

2. Manage the work, let people self-organize around it

3. Evolve your management policies to improve customer & business outcomes


Seeing Services


H

FF OM

NK

J

I

Pull

For each service implement a Kanban “pull” system

Ideas

D

E

A

DevReady

G

5Ongoing

Development Testing

Done3 3

TestReady

5

F

B

CPull

Pull

*

There is capacity here

UATReleaseReady

∞ ∞

Pulling work from development will create capacity here too –

the pull signals move upstream!

Now we have capacity to replenish our ready

buffer


Commitment is deferred

H

EC A

D

Commitment point

FF FF FF F

G

Pull

Wish to avoid aborting after commitment

IdeasDev

Ready5

Ongoing

Development Testing

Done3 3

TestReady

5

UATReleaseReady

∞ ∞

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

to take delivery.

Ideas remain optional and (ideally) unprioritized


Discovery Kanban Prepares OptionsReady

forEngin-eering

F

H

I

Comm-itted

D

4 Ongoing

Development

Done3

JK

12

Testing

Verification3

L

Commitment point

4 -

Requi-rementsAnalysis

2412 -

RiskAnalysis

4824 -

Poolof

Ideas

∞

Min & Max limitsensure sufficientoptions are alwaysavailable

Committed WorkOptions

Discarded

OReject

P Q

$$$ spent acquiring options $$$ spent converting

options

Embedded Options

Done

Delivery KanbanDiscovery Kanban


RolesReady

forEngin-eering

F

H

I

Comm-itted

D

4 Ongoing

Development

Done3

JK

12

Testing

Verification3

L

Commitment point

4 -


2412 -

RiskAnalysis

4824 -

Poolof

Ideas

∞

Service Delivery ManagerService Request Manager

Discarded

OReject

P Q

Marshals Options Manages Flow

Done


The Kanban Method

Change Management Principles

1. Start with what you do now Understanding current processes, as actually practiced Respecting existing roles, responsibilities & job titles

2. Gain agreement to pursue improvement through evolutionary change

3. Encourage acts of leadership at all levels


The Kanban Method

General Practices

1. Visualize (with a kanban board 看板 )

2. Limit work-in-progress (with kanban かんばん )

3. Manage flow4. Make policies explicit5. Implement feedback loops6. Improve collaboratively, evolve experimentally

(using models & the scientific method)


StrategyReview

RiskReview

Monthly

ServiceDeliveryReview

Bi-WeeklyQuarterly

KanbanMeeting

Daily

OperationsReview

Monthly

Replenishment &Commitment

Meeting

Weekly

DeliveryPlanningMeeting

Per delivery cadence

change change

change

change

change

change

change change

change

info

info

info

info

info

infoinfo

info

info

change info

Kanban Cadences


Kanban Design Patterns


Personal Kanban

Backlog

F

HE

C A

G

D

Next Done

3

In-progress

3∞ ∞

IJ


Aggregated Personal Kanban

Backlog

F

H

E

C A

TeamMember

G

D

Next Done3

In-progress

3

Joe

Peter

Steven

Joann

per person∞ ∞per person

At this level, we are still focused on organizing & managing people rather than enabling people to self-organize around the

work & managing its flow


Team Kanban

Backlog

F

HE

C A

G

D

Next Done

3

In-progress

3∞ ∞

GY

PB

DE

IJ Avatar for each

team memberStill at a single team level but maturing

to focus on managing work and less on managing

workers


Poorly Understood or Emergent Workflow

F

HE

C A

G

D

Next Done3

In-progress6 ∞

GY

PB

DE

IJ

Wide in-progress column with tickets positioned

left-to-right with estimate of

completeness

Horizontal position shows percentage complete


A

Proposed Projects

B

D

E

F

K

H

G

Projects-in-progressComplete0%

Complete100%

C

Simple Portfolio Visualization

J

I

M

N

O

L

Tickets represent Projects, MVPs or MMFs



AStrategic40% budget

Operational40% budget

Tactical20% budget

Allocation of personnelTotal = 100%

B

D

E

F

K

H

G


Complete100%

C

Color may indicatecost of delay (or other risk)

Visualizing Risk in a Portfolio Kanban

Size of ticket indicates budget

A total of 4 risk dimensions are shown on this board

Schedule progressBusiness contribution capacity allocation

Cost of Delay (and class of service)Project size or budget



A

Proposed Projects

D

E

F

K

H

G


Complete100%

C

Earned Value Portfolio Visualization

J

I

M

N

O

L

percentage scope complete

Perc

enta

ge b

udge

t/sc

hedu

le u

sed

Size of ticket indicates budget

B

Safe

ManagementAttentionRequiredAt Risk


O

P

R

N

M

L

J

Per Person WIP Limit

Done

F

H E

C

A

I

Pending

G

DGY

PB DE

MN

AB

Dev/Build/Test/Deploy

DevReady

GY

GY

PB

PB

MN

MN

DE

DE

ABAB

K

Bench

Specify

B

∞∞ ∞

Unbounded

Queue

DelayedWIP

At this level, we are focused on managing work

and enabling people to self-organize around it but we aren’t limiting WIP in the system as a whole. Hence, service delivery will not be predictable

Moving beyond a single team to a service delivery workflow


Decoupled Cadences & Constant WIP

Backlog

F

HE

C AG D

Committed

ReadyFor

Delivery

In-progress

6

∞ ∞

GY

PB

DE

I

J

Delivered

∞

Replenishment

The frequency of system replenishment should reflect

arrival rate of new information and the transaction &

coordination costs of holding a meeting

The frequency of delivery should reflect the transaction &

coordination costs of deployment plus costs &

tolerance of customer to take delivery

WIP limit should be sufficient to keep the team busy until the next replenishment

meetingDelivery

CONWIP


Aggregated Team Kanban

Done

Poolof

Ideas

FH E

C A

I

NextDeploy-

mentReady

GD

GYPB

DEMN

5 ∞

P1

AB

Ongoing

Development Testing

Done Ongoing Done

3 3

Team 1 Kanban

∞ ∞

Team 2 Kanban



Done

Poolof

Ideas

FH E

C A

I

NextDeploy-

mentReady

GD

GYPB

DEMN

5 ∞

P1

AB

Ongoing

Development Testing

Done Ongoing Done

3 3∞ ∞

Also known

as “infinite

done queues”



Done

Poolof

Ideas

FH E

C A

I

NextDeploy-

mentReady

GD

GYPB

DEMN

5 ∞

P1

AB

Ongoing

Development Testing

Done Ongoing Done

3 3

Infinite limits on Done columns means that there really isn’t a kanban pull system present.

This style of proto-kanban controls multi-tasking but doesn’t limit workflow WIP

∞ ∞


H

QP

OM

LK

J

I

Kanban can be represented with slots

Ideas

D

E

A

Engin-eeringReady

G

Ongoing

Development TestingDone

TestReady

F

B

CPullPull

*

UATDeploy-

mentReady

An empty slot signals pull

Pull

Pull

PullIPhysical slot is a kanban

The tickets on the board are not the kanban. Believing the tickets are the kanban is a common misconception

This board and the next two all look different but they all visualize the

same identical kanban system


H

FF OM

NK

J

I

Using movable tokens as kanban is more flexible

Ideas

D

E

A

I

DevReady

G

Development TestingTest

Ready

F B

C

UATReleaseReady

In-progressLegend

Done

Blocked - issue

Blocked - defect

Colors are used to denote state

Physical token such as a magnet is a kanban

Moving done items down below a line is an optional enhancement

seen in some implementations


H

FF OM

NK

J

I


Ideas

D

E

A

I

DevReady

G


Ready

F B

C

UATReleaseReady

In-progressLegend

Done

Blocked - issue

Blocked - defect

Override on kanban limit introduces additional

“blocked – issue” kanban

People working on blocked item “A”

have been redirected to work

on item “I”


H

FF OM

NK

J

I


Ideas

D

E

A

I

DevReady

G


Ready

F B

C

UATReleaseReady

In-progressLegend

Done

Blocked - issue

Blocked - defect

Using physical slots in the previous example has been shown to create

inertia to modification & improvement

Using movable tokens allows for WIP limits to be easily modified and provides a natural signal

token mechanism


H

FF FF FF J

I

Declaring a kanban quantity is even simpler

Ideas

D

E

A

I

Engin-eeringReady

G

5Ongoing

Development Testing

Done

3 3

TestReady

5

F

B

CPull

PullThese are the virtual kanban

*

These are the virtual kanbanThese are the (virtual) kanban These WIP limits serve the same function as the

magnets or slots

This board has even less maintenance overhead than the magnet board

UATDeploy-

mentReady

∞ ∞

A “virtual kanban” pull signal is created by subtracting the column

number from tickets currently in the column


Discovery Kanban Prepares OptionsEngin-eeringReady

F

H

I

Comm-itted

D

4 Ongoing

Development

Done3

JK

12

Testing

Verification3

L

Commitment point

4 -


2412 -

RiskAnalysis

4824 -

Poolof

Ideas

∞

Min & Max limitsensure sufficientoptions are alwaysavailable

Discarded

OReject

P Q

Done

Delivery KanbanDiscovery Kanban


Single Service, Multiple Classes of ServiceAllocate capacity with kanban limit per color

5 4 4 5 2= 20 total

Allocation

10 = 50%

...

+1 = +5%

4 = 20%

6 = 30%

InputBuffer In Prog DoneDoneIn Prog

DevelopmentAnalysis BuildReady Test

ReleaseReady


3 Services Aggregated Together

5 4 4 5 2 = 20 total

Change Req12

Maintenance2

Production Defect6

AllocationTotal = 20

InputBuffer In Prog Done

BuildReady Test

ReleaseReadyDoneIn Prog

DevelopmentAnalysisReleased


ChangeRequest

s3

1

Prod.Defects

Maintenance

UsabilityImproveme

nt

2

1

Improving Liquidity through Labor Pool Flexibility

Teams

F

HE

C A

Engin-eeringReady

G

D

GY

PBDE

MN

2

P1

AB

Ongoing

Analysis Testing

Done VerificationAcceptance3 3Ongoing

DevelopmentDone3

Joe

Peter

Steven

Joann

David

Rhonda

Brian

Ashok

TeamLead

Junior who will be rotated through all 4 teams

Generalist or T-shaped people who can move flexibly across rows on the board to keep work

flowing

It’s typical to see splits of fixed team workers versus flexible system

workers of between 40-60%

Roughly half the labor pool are flexible workers

Promotions from junior team member to flexible

worker with an avatar clearly visualize why a

pay rise is justified. Flexible workers help manage liquidity risk

better!


Organizational Maturity


Personal Kanban

Aggregated Personal Kanban

Team Kanban

Emergent/Undefined Workflow

Per Person WIP LimitCONWIP

Physical spacekanban

Physical token kanban

Virtual KanbanClasses of service

Capacity allocationLiquidity optimization

Aggregated teams

Patterns of Kanban Board Designs


Relief

from

Overb

urde

ning

Predictability

Fast, Smooth Flow

Risk Hedging

Risk Management

Benefits of improving maturity


Lear

ning

& im

prov

emen

t

Formula for evolutionary change …

Stressor Reflection

Mechanism Leadership

Stre

ssor

Refle

ctio

n M

echa

nism

KanbanMeeting

Risk Review & SDR

Ops Review

Strategy Review

Personal WIP Limit

Column WIP Limit

RowWIP Limit

Strategy vs Capability

Visualization

Replenishment & Delivery

Planning

Personal Reflection


Conclusion


Team KanbanPractitioner

Kan

ban

Syst

emD

esig

n

EnterpriseServicesPlanning

Lean Kanban Class Curricula

Kan

ban

Man

agem

ent

Prof

essi

onal

Kan

ban

Coa

chin

g Pr

ofes

sion

al

Acc

redi

ted

Kan

ban

Trai

ner


Thank you!


About

David Anderson is an innovator in management of 21st Century businesses that employ creative people who “think for a living” . He leads a training, consulting, publishing and event planning business dedicated to developing, promoting and implementing new management thinking & methods…He has 30+ years experience in the high technology industry starting with computer games in the early 1980’s. He has led software organizations delivering superior productivity and quality using innovative methods at large companies such as Sprint and Motorola.David defined Enterprise Services Planning and originated Kanban Method an adaptive approach to improved service delivery. His latest book, published in June 2012, is, Lessons in Agile Management – On the Road to Kanban.David is Chairman & CEO of Lean Kanban Inc., a business operating globally, dedicated to providing quality training & events to bring Kanban and Enterprise Services Planning to businesses who employ those who must “think for a living.”


Appendices


Books


2010 – Kanban “blue book”


2012 Lessons in Agile Management

The heavily under-rated book that underpins the Kanban Coaching Masterclass and most of the theory behind the Kanban Method


2014 Kanban from the Inside

patterns of kanban maturity

Leadership & Management