kanban = violet pill
DESCRIPTION
Kanban talk presented at Italian Agile Day 2011 #iad11TRANSCRIPT
Kanban
violet pill
Gaetano Mazzanti @mgaewsj
Gama-Tech
no change disruptive change
révolution?
inspired by Joakim Sunden
changes often end up being local: big impact on a few people, small/no impact on the whole org
a storm in a glass?
change impacts
just here
company
technical dept
SW teams
(scared) orgs, prefer small improvements, no change in roles and responsibilities (and they don’t like to be told that managers should be kept out of the loop)
no cross functional team?
no product owner?
firefighting?
people working on multiple projects?
scared to change?
sometimes you cannot
transform first
observe, visualize work, apply continuous improvement,
then transform
Purpose > Observe, Measure > Method
method should come last!
a complex journey, known destination
same pattern: Code Product Process
(BTW you need a Vision…)
un
un
Kanban 101
make work visible limit Work In Process (WIP) help work to flow
kanban vs Kanban 1950 2004
kanban & JIT in manufacturing
only what is needed only in the amounts needed only when it is needed
pull
simple kanban home milk delivery
muri, mura, muda
if you can’t see it you can’t manage it
Limit WIP
let work flow let work flow
context matters
principles of the Kanban method
start with what you do now pursue incremental, evolutionary change respect the current process, roles, responsibilities & titles
David J Anderson
five core properties
visualize the workflow limit WIP manage flow make process policies explicit improve collaboratively (let people design their own process)
yes, and…
two rules for improv…isation: 1. agree 2. add
EMENT Tina Fey
“the aim of kanban is to make troubles come to the surface and link them to kaizen activity”
Taichi Ohno, 1984
map the mess
workflow bottlenecks
queues teamwork
time type of work
visible make
empower the team to fix it
expose dysfunctions
do you keep stinky food in the fridge?
visualize your actual work(flow)
backlog to do in progress done test
B
C
D
F E
A
visualize your actual work(flow)
backlog to do in progress done test
B
C
D
F E
A
visualize your actual work(flow)
backlog to do in progress done test
B
C
D
F E
A
visualize your actual work(flow)
backlog to do in progress done test
B C
D
F E
A
visualize your actual work(flow)
backlog to do in progress done test
B
C
D
F E
A
limit WIP
backlog to do in progress done test
D G
H
J I
F
B
A E
C
limit WIP measure flow
backlog to do in progress done test
D G
H
J I
F
B
A E
C
cycle time
lead time
why should we limit WIP?
Little’s Law
cycle time =
WIP / throughput (throughput = average completion rate)
Little’s Law
length of queue =
arrival rate * average wait time
why should we limit WIP?
why should we limit WIP?
too much WIP increases cycle time
too much WIP leads to queues
queues lead to delays queues lead to multitasking
queues lead to … many additional dysfunctions (variability, lower quality, demotivation, higher risks, etc.)
Cost of Delay
source David J Anderson
causes of delay
multitasking sucks
ABC ABC ABC AAA BBB CCC
working 4me context switching 4me 0
20
40
60
80
100
1 2 3 4 5
working 4me context switching 4me
number of simultaneous projects
percen
t
source Jerry Weinberg
multitasking sucks multitaskers optimize for capacity,
not for throughput
ABC ABC ABC AAA BBB CCC
let work flow
backlog to do in progress done test
D G
F
B
A E C H
J I
can’t push anything here
let work flow
backlog to do in progress done test
D G
F
B
A E C H
J I
let work flow
backlog to do in progress done test
D G
F
B
A E
C H
J I
let work flow
backlog to do in progress done test
D G
F
B
A E
C H
J I
who’s working on what?
backlog to do in progress done test
D G
H
J I
F
B
A E
C
total WIP
backlog to do in progress done test
D G
H
J I
F
B
A E
C
total WIP = 4
buffers
backlog to do in progress done test
D
G H
J I F
B
A
E
C
[
[
buffers with no WIP limit
backlog to do in progress done test
D
I
J
L K
G
B
A
E
C
F
H
no WIP limits => queue
backlog to do in progress done test
G
L
N
P
F B
A
E
C D
K M
O
H
J I
Q
no WIP limits => queue
backlog to do in progress done test
L
N
P B
A K M
O
Q
flow = speed * density
Km per hour
vehicles per hour
flow = speed x density
vehicles per Km
Km per hour
density flow
speed
queues cumulative flow diagram
time
cumulative quantity
WIP
cycle time
cumulative flow diagram large batches => long queues
time
cumulative quantity
cumulative flow diagram small batches => short queues
time
cumulative quantity
what to do next (help)
backlog to do in progress done test
D
F A
E
C
B
G
H
J I
what to do next (pull)
backlog to do in progress done test
D
F A
E
C
B
G
H
J I
stuck (cannot break WIP limit)
backlog to do in progress done test
D G H
J I
F
B
A
E C
stuck (nothing to pull)
backlog to do in progress done test
D E G
I H
F B
A
C
slack (%)
absorb variations
% capacity utilization
queue size
queue size grows exponentially at high capacity 0
5
10
15
20
25
0 10 20 30 40 50 60 70 80 90 100
no testers
non-instant availability
non instant availability external parking
what’s on a stickie?
this is just an example
ID 326
As a user I want to So that
due date 12 Nov 2011
blocked
type of work
types of work
standard due date
expedite bug
classes of service and WIP
standard work = 60%
expedite = 10%
due date = 20%
bug = 10%
classes of service, WIP, expedite lane
backlog to do in progress done test
D
H
J I
F B
A E
C
6
M L K
2
1
1
O
Q
N
P
EXPEDITE LANE
G
cost of delay & classes of service
cost
6me
cost
6me
cost
6me
explicit policies
backlog to do in progress done test
=> Done: -‐ Acceptance Tests verified on test server -‐ Signed Off by Marke6ng -‐ Test coverage > 80%
=> In Progress: -‐ Acceptance Test defined
-‐ standups at 11.45 am -‐ 2 hours pairing 3 days/week -‐ retrospec6ve every Friday at 2pm
multiple projects
project A
project B
project C
multiple projects
backlog to do in progress done test
J F B
A E
C
M L K
O H
G
D
N
people working on
multiple parallel projects
portfolio Kanban
ouch!
portfolio Kanban one month later
world is not linear…
backlog to do in progress done test
multiple routes
backlog to do
L
M N
BACKLOG
deploy done
B
A C
DONE
design code
D
E H
DEVELOPERS test
script test
G
F I
SUPPORT
networked Kanban
source Jurgen Appelo
Kanban is not a process Kanban is something that is overlaid over an existing process Kanban is a catalyst for change
a drug for all seasons
Agile Teams running out of steam
process maturity
chaotic
traditional
gateway drug theory
softer drugs (Kanban) can lead to harder drugs (Scrum, XP, whatever…)
Michael Sahota
a trojan horse?
dogma? no, thanks
don’t stop improving
don’t stop improving
time
process
Z Z Z Z Z
overburden
task switching
command & control
Kan’t Ban?
Kan…but? YES BUT
it’s a never ending journey
enjoy the ride
learn from the people plan with the people begin with what they have build on what they know
Lao-Tzu
Gaetano Mazzanti @mgaewsj Gama-Tech
Kanban
it’s a never ending journey
enjoy the ride
Gaetano Mazzanti @mgaewsj Gama-Tech
Kanban