the Kanban Dependency Management Chart

1. Dependency Management
More information: mauvisoft.com
© Mauvius Group Inc. All rights reserved. Reproduction by permission only.
More information: mauvisoft.com
•
S
c
h
o
ol of Manag
e
m
e
n
t
•
D
a
vid J Anderso
n
12. CLASSES OF BOOKING
GENERAL DEPENDENCY
MANAGEMENTWITH KANBAN
11.
PARKING LOTS USED TO HOLD
ITEMS BLOCKED DUE TO
DEPENDENT WORK EXTERNAL
TO THE IMMEDIATE BOARD
17. BLOCKER CLUSTERING
18. RISK REVIEW
19. OPERATIONS REVIEW
20. DELIVERY PLANNING MEETING
1. CHECKBOXES
ON KANBAN TICKET DESIGN
5. ROWS ON
KANBAN BOARDS
6.
SEQUENTIAL DEPENDENCIES
SHOWN FROM LEFT TO RIGHT
IN THE DESIGN OF WORKFLOW
KANBAN BOARDS
10.
PARENT-CHILD DEPENDENCIES
IN THE DESIGN OF TWO-TIERED
KANBAN BOARDS
13. DYNAMIC RESERVATION
SYSTEMS
15.
TRIAGE TABLES (BASED ON
PROBABLE COST OF DELAY IN
STARTING)
14.
MAPPING SHARED SERVICES
TO AN EXISTING BOARD USING
A COLUMN WITH A WIP LIMIT OR
AVATARS FOR INDIVIDUALS
16.
MARKING BLOCKED TICKETS
WITH DIFFERENT COLORS
TO INDICATE THE TYPE OF
DEPENDENCY
4.
CAPACITY ALLOCATION FOR
TYPES OF WORK OR SOURCES
OF DEMAND
2. DECORATING TICKETS TO SHOW
PEER-TO-PEER DEPENDENCY
7.
SPLIT-MERGE BOARD DESIGN
TO SHOW INTEGRATION
DEPENDENCIES
3.
USE OF DATE FIELDS ON
TICKETS TO SHOW INTEGRATION
DEPENDENCY DATES
There are many specific practices in the Kanban Method that contribute to an
effective approach to dependency management;​for example:
ID TITLE
Lorem opossum fur nomadic beast tail white at then snout
marsupial.Then solitary what a opossum didelphimorph
oil bitey is omnivore.
Start
End
Due
Other
Requested
Subtask 1
required
complete
Subtask 2
Subtask 3
Decorators to
highlight risk,
priori�es or
others
H
07/23/20
07/25/20
08/10/20
Decorators to
highlight risk,
priorities, or
dependencies on
others
Checkboxes
to indicate
subtasks
Ticket ID and
work item
description
Color of
the ticket
Time stamps
to track lead
time
Visualization
of time spent
or SLA
 

Selected
Work type A
Work type B
Work type C
10
5
5
20
System-level WIP
Complete
In Progress Done
“We will spend
half of our
capacity for work
type A, and 25% each
for work types B
and C.”
4
5 2 2
4
4
4
Next
In Prog done
input
buffer
analysis Build�
R eady
Test R elease
R eady
dev
In Prog done
...
concurrent activities
test dev
In Prog
split
combine
team 1
team 2
req 5
Features
(parents)
User stories
(children)
Features
(parents)
Parent-child dependencies can be
represented with 2-tiered boards.
analysis
feature development
done
test
stories development
test
design code
team 3
team 4
team 5
team 6
sla = 5 days
Next
In Prog done
waiting on external
group
Late against SLA
5 4 3 4 2 2
input
Buffer
analysis
Build�
R eady
Test
R elease
R eady
Next
In Prog done
development
dev
R eady
req 5
Features
(parents)
analysis
feature development
done
test
stories development
test
design code
team 3
team 6
sla = 5 days
Column WIP Limit = 5
Test is a shared service across 5 dev teams.
In this example, testing was offshore in Chennai, India.
5
Small orange tickets are avatars
for people from shared services
such as enterprise architecture and user experience design.
Amanda
Nick
Daniel
Maria
Ted
Steve
Matt
Lucy Emily
Alex Sarah
Katy
Next
input
buffer
analysis Concurrent
Activities
Build
R eady
Test R elease
R eady
blocking
issue
defect
8. CLASSES OF DEPENDENCY
MANAGEMENT
9. CLASSES OF SERVICE
POOL OF IDEAS READY
(2) (2)
(3)
ACTIVITY
ONGOING ONGOING
DONE DONE
ACTIVITY DONE
CLASS OF DEPENDENCY MANAGEMENT & CLASS OF RESERVATION
CLASS OF
DEPENDENCY
MANAGEMENT
CUSTOMER TICKET
AND EXPECTATIONS
CALLED SERVICE
TICKET
CUSTOMER TICKET
RESERVATION
CALLED SERVICE
RESERVATION
CUSTOMER-FACING
APPLICATION SERVICES
INTERNALLY FACING
PLATFORM OF SHARED
SERVICES
NATURE OF
DEPENDENCY
MANAGEMENT
No dependency management;
dynamic, just-in-time
dependency discovery.
Dependency impact is built
into customer lead time
distribution.
We start early enough & cost
of delay is low enough that
we don’t need to explicitly
manage the dependency.
We wish to mitigate the tail risk
in the customer-facing lead
time by ensuring dependency
delivery is predictable and
reliable as a consequence of
reserved capacity on the called
service.
Assume a dependency exists: filter
lead time probability density function
for this assumption. Make a standby
reservation just in case we have a
dependency. Dependency should be
given Fixed Date class of service to
mitigate tail risk on customer request.
We want high confidence in the start
time for customer lead time. We take no
risk on dependent capacity becoming
unavailable.
NO MARGIN FOR ERROR!
We want 100% confidence in the start
time for customer lead time and no risk on
dependent capacity availability.
ITEM IS NEEDED ASAP!
We do not care about dependency
management or reservations – just do it!
Just-in-time, dynamic dependency
discovery
“RESERVED” Class of Booking
“STANDBY” Class of Booking “RESERVED” Class of Booking
“GUARANTEED” Class of Booking
“GUARANTEED” Class of Booking
Demand: INTANGIBLE
Demand: INTANGIBLE
Demand: STANDARD Demand: STANDARD
Demand: STANDARD
Demand: FIXED DATE
Demand: FIXED DATE Demand: FIXED DATE Demand: FIXED DATE
Demand: FIXED DATE Demand: EXPEDITE
Demand: EXPEDITE
Analyze & detect dependency.
DoR requires confirmed “reserved”
booking on called service.
Analyze & detect dependency.
DoR requires confirmed “Guaranteed”
booking on called service.
Undetermined wait:
NO WIP LIMITS!
WIP LIMITS! NO WAIT: PREEMPTS OTHER TICKETS
Dynamic, just-in-time
dependency discovery;
capacity allocation on called
service to guarantee service
when needed.
Assume dependency exists.
Use filtered lead-time
distribution to determine start
time and class of service;
standby reservation on called
service (just in case); dynamic,
just-in-time dependency
discovery.
Up-front dependency
detection with reserved Class
of Booking on called service;
definition of ready requires up-
front analysis and a reserved
Class of Booking.
Up-front dependency
detection with guaranteed
class of booking on called
service; definition of ready
requires up-front analysis and
a guaranteed called service
reservation.
No dependency management;
dynamic dependency
discovery; expedite
dependencies when
discovered.
DON’T CARE
OPTIONAL STANDBY
NONE
OPTIONAL STANDBY
NONE
OPTIONAL RESERVED
STANDBY
RESERVED
RESERVED
GUARANTEED
GUARANTEED
NONE
NONE
FIXED DATE
TRUSTED
AVAILABILITY
GUARANTEED
ON‑TIME
TAIL-RISK
MITIGATION EXPEDITE
1 2 3 4 5 6
1 2 3 4 5 6
Lead Time
10 30 60
Lead Time
10 30 60
Filtered
for Known
Dependency
Filtered
Lead Time
10 30 60
Filtered
for Known
Dependency
Filtered
Lead Time
10 30 60
Filtered
for Known
Dependency
Filtered
Lead Time
10 30 60
Filtered
for Known
Dependency
Filtered
Lead Time
10 30 60
WE DO NOT CARE! RESERVED CAPACITY WE DO NOT CARE!
Lead Time
1 5 15
Filtered by
Calling Service
Work Type
Lead Time
1 5 15
Filtered by
Calling Service
Work Type
Lead Time
1 5 15
Filtered by
Calling Service
Work Type
Lead Time
1 5 15
Filtered by
Calling Service
Work Type
Lead Time
1 5 15
Filtered by
Calling Service
Work Type
Lead Time
1 5 15
Filtered by
Calling Service
Work Type
POOL OF IDEAS READY
(2) (2)
(3)
ACTIVITY
ONGOING ONGOING
DONE DONE
ACTIVITY DONE
A
B
POOL OF IDEAS POOL OF IDEAS
READY READY
(2) (2)
(2) (2)
(3) (3)
ACTIVITY ACTIVITY
ONGOING ONGOING
ONGOING ONGOING
DONE DONE
DONE DONE
ACTIVITY ACTIVITY
DONE DONE
POOL OF IDEAS READY
(2) (3)
(4)
ACTIVITY
ONGOING ONGOING
DONE DONE
ACTIVITY DONE
A
B
(3)
(6)
POOL OF IDEAS POOL OF IDEAS POOL OF IDEAS
READY READY READY
(2) (2) (2)
(3) (3) (3)
(4) (4) (4)
ACTIVITY ACTIVITY ACTIVITY
ONGOING ONGOING ONGOING
ONGOING ONGOING ONGOING
DONE DONE DONE
DONE DONE DONE
ACTIVITY ACTIVITY ACTIVITY
DONE DONE DONE
A A A
B B B
(3) (3) (3)
(6) (6) (6)
WEEK
22
WEEK
23
WEEK
24
WEEK
25
WEEK
26
WEEK
27
WEEK
28
WEEK
30
WEEK
29
WEEK
31
WEEK
22
WEEK
23
WEEK
24
WEEK
25
WEEK
26
WEEK
27
WEEK
28
WEEK
30
WEEK
29
WEEK
31
POOL OF IDEAS POOL OF IDEAS POOL OF IDEAS
READY READY READY
(2) (2) (2)
(2) (2) (2)
(3) (3) (3)
ACTIVITY ACTIVITY ACTIVITY
ONGOING ONGOING ONGOING
ONGOING ONGOING ONGOING
DONE DONE DONE
DONE DONE DONE
ACTIVITY ACTIVITY ACTIVITY
DONE DONE DONE
< FIXED DATE >
-COS-
< FIXED DATE >
-COS-
WEEK
22
WEEK
23
WEEK
24
WEEK
25
WEEK
26
WEEK
27
WEEK
28
WEEK
30
WEEK
29
WEEK
31
WEEK
22
WEEK
23
WEEK
24
WEEK
25
WEEK
26
WEEK
27
WEEK
28
WEEK
30
WEEK
29
WEEK
31
WEEK
22
WEEK
23
WEEK
24
WEEK
25
WEEK
26
WEEK
27
WEEK
28
WEEK
30
WEEK
29
WEEK
31
< FIXED DATE >
-COS-
< FIXED DATE >
-COS-
< FIXED DATE >
-COS-
POOL OF IDEAS READY
(2) (3)
(4)
ACTIVITY
ONGOING ONGOING
DONE DONE
ACTIVITY DONE
A
B
(3)
(6)
Critical and immediate
cost of delay; it can
exceed other kanban limit
(bumps other work).
EXPEDITE
delay
cost
Critical and immediate
cost of delay; it can
exceed other kanban limit
(bumps other work).
EXPEDITE
delay
cost
Significant cost of delay is
incurred on a specific date
(a hard deadline).
FIXED DATE
ZERO TOLERANCE
delay
cost
Significant cost of delay is
incurred on a specific date
(a hard deadline).
FIXED DATE
delay
cost
Significant cost of delay is
incurred on a specific date
(a hard deadline).
FIXED DATE
delay
cost
Increasing urgency—
cost of delay is shallow
but accelerates before
levelling out.
delay
cost
STANDARD
WITH DEADLINE
Increasing urgency—
cost of delay is shallow
but accelerates before
levelling out.
delay
cost
STANDARD
WITH SLE
Increasing urgency—
cost of delay is shallow
but accelerates before
levelling out.
delay
cost
STANDARD
WITH SLE
INTANGIBLE
Cost of delay may be
significant but is not
incurred until significantly
later (if at all).
delay
cost
INTANGIBLE
Cost of delay may be
significant but is not
incurred until significantly
later (if at all).
delay
cost
Cost of delay goes up
significantly around a
known & fixed date.
FIXED DATE
Cost of delay goes up
significantly around a
known & fixed date.
FIXED DATE
delay
cost
delay
cost
CLASSES OF BOOKING
Standby
Reserved
Guaranteed