Classes of Service - the "sonic screwdriver" of Kanban Coaching

Email dja@leankanban.com Twitter @lki_dja Copyright Lean Kanban Inc.
Classes of Service
the sonic screwdriver of the Kanban coach
Reductionist determinism is
the “dark side,” resist it with
Classes of Service
David J. Anderson
Chairman, Lean Kanban Inc
Swift Kanban Webinar
May 2017

The Sonic Screwdriver is
the utility tool of Dr. Who!
Useful for opening locks through to
befuddling or sedating any and all alien
enemies. The Sonic Screwdriver is the
only weapon a Time Lord ever needs

Sonic Screwdrivers are benign
yet fiendishly powerful!
A sonic screwdriver does no harm or lasting
damage
It’s lightweight, easy to carry and deploy but it
requires calibration and configuration for each
situation
Its versatility is its strength!

Classes of Service

Classes of Service are to
the Kanban Coach what
the Sonic Screwdriver is
to Dr. Who!...
A lightweight, highly configurable, very
versatile tool for coping in uncertain
and unpredictable situations

A Class of Service is defined
by a set of policies which
determine how something
should be treated
In a Kanban system, a class of service typically
determines the priority of selection of a ticket
and how quickly it will flow across the board

Classes of Service are typically visualized using color
Expedite – white; critical; top priority; no
waiting; pre-empts other work; can exceed
other kanban limit (bumps other work); limit 1
Fixed date – orange; critical cost of delay
after externally controlled deadline; give
priority where necessary
Standard - yellow; typically flowed on a FIFO
basis based on start date
Intangible – blue; not urgent, may be critical
over long term; protect capacity; risk hedge
against Expedite; select & flow only when no
Expedite or Fixed Date items are present
Class of service and its policiesColorSelection
1st
2nd
3rd
4th

Capacity allocated by class of service
with kanban limit per color
5 4 4 5 2 = 20 total
Allocation
10 = 50%
...
+1 = +5%
4 = 20%
6 = 30%
Input
Queue In Prog DoneDoneIn Prog
DevelopmentAnalysis Build
Ready Test
Release
Ready

Classes of Services are a
critical tool in risk
management
Classes of service have two main roles in
Kanban and Enterprise Services Planning
1. Improving predictability of lead time for
high risk items
2. Improving dependency management

Classes of Service are
used to affect lead times
and improve
predictability of flow
Classes of service are used to give
some items priority & reduce waiting
times in the workflow

Reductionist deterministic
planning is the way of the
Dark Side
A Jedi must embrace uncertainty
Learn to manage probabilistically, you must!

Classes of Service are also
used to minimize the burden
of dependency management
Like purchasing a “standby” ticket for a flight,
we can provide classes of service for
scheduling in a kanban reservation system

Flow Efficiency

Test
Ready
Flow Efficiency
F
E
I
G
D
GY
PB
DE MN
P1
AB
Customer Lead Time
Waiting Waiting WaitingWorking
* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012
** Hakan Forss, Lean Kanban France, Oct 2013
Ideas
Dev
Ready
5
Ongoing
Development Testing
Done
3 35
UAT
Release
Ready
∞ ∞
Flow efficiency measures
the percentage of total lead
time is spent actually
adding value (or
knowledge) versus waiting
Flow efficiency % = Work Time x 100%
Lead Time
Flow efficiencies of 1-5% are
commonly reported. *, **
> 40% is good!
Working WaitingWorking
Multitasking means time spent in
working columns is often waiting
time

Work flows better when WIP levels are low
Done
Pool
of
Ideas
F
E
I
Engin-
eering
Ready
Deploy-
ment
Ready
G
D
2 ∞
Ongoing
Development Testing
Done Verification Acceptance
8 3
N
With excessive WIP in the system tickets must wait
in “done” states for longer periods of time
The period spent waiting in a “done” state is non-
deterministic because the risk profile and skills
required for a piece of work determine its selection
against the others it is waiting alongside.

Work flows better when workers are well matched to work
Done
Pool
of
Ideas
F
E
I
Engin-
eering
Ready
Deploy-
ment
Ready
G
D
2 ∞
No Pull
Ongoing
Development Testing
Done Verification Acceptance
3 3
Work flows through a kanban system when work
items are well matched with skills of available staff.
When there is a poor match work waits for a
suitable worker to become available.
For work to flow freely in a kanban system, we
must have work available to pull and suitably
matched workers available to pull it. Hence, the
act of pulling is the indicator that an item of
work was matched to available workers and flow
happened.

“pull criteria” policies affect flow & may cause delay in activity states
5 4 43 2 2
Input
Buffer
Dev
Ready In Prog Done
Build
Ready
Test Release
Ready
Stage Prod.
DoneIn Prog
DevelopmentAnalysis
Policies
~~~~~~
~ ~ ~ ~
Policies
~~~~~~
~ ~ ~ ~
Policies
~~~~~~
~ ~ ~ ~
Policies
~~~~~~
~ ~ ~ ~
Delay
until criteria
are met
We may choose to reduce flow
efficiency in order to boost quality
or meet regulatory requirements.
Different risks affect flow time

Flow through a kanban system is non-deterministic
5 4 43 2 2
Input
Buffer
Dev
Ready In Prog Done
Build
Ready
Test Release
Ready
Stage Prod.
DoneIn Prog
DevelopmentAnalysis
These are not queues !!!
But buffers or
“supermarkets”
Work waiting is seldom queueing unless the class of
service describes a queueing discipline such as FIFO
“done” and “ready” states in kanban systems are
not queues, they are buffers or supermarkets. This
means selection can be random & “queueing
time” cannot be predicted.
Think of them as “beauty contests”

Waiting Waiting WaitingWorking Working WaitingWorking
Test
Ready
Implications of low Flow Efficiency
F
E
I
G
D
GY
PB
DE MN
P1
AB
Ideas
Dev
Ready
5
Ongoing
Development Testing
Done
3 35
UAT
Release
Ready
∞ ∞
Low flow efficiency means that most of lead
time is influenced by environmental factors
that are unlikely to change soon
Customer Lead Time
In a low flow
efficiency
environment, Class of
service is much more
likely to influence lead
time than any other
factor
As a result, lead time is
not very sensitive to the
size or complexity of a
single work item, or to
the specific people
involved or their
individual capabilities

Summarizing Flow Efficiency
Flow efficiencies are typically low on average
Lead time mostly consists of waiting time
Periods spent waiting are non-deterministic
Lead times are non-deterministic
Estimations of effort or working time are of little value as they represent
a small percentage of the lead time
Predicting lead time with accuracy is impossible

Classes of Service correlates to flow efficiency
Expedite – High flow efficiency. Often close to
100%. Preempts other work – almost no
waiting time. Gaussian lead time distribution
Fixed date – Higher flow efficiency. Some
waiting. Tend to defer commitment until “just-
in-time” & give flow priority
Standard – Low flow efficiency in conditions of
high worker utilization or heterogeneous skills
requirements. Non-deterministic wait times
Intangible – Very low flow efficiency. Defers to
Expedite or Fixed Date items. Often
preempted. Long, non deterministic wait times
Class of service and its policiesColorSelection
1st
2nd
3rd
4th

Scheduling

“When will [my item] be done?”
Asking “When will [my item] be ready?” is the wrong question
 Lead times are non-deterministic unless an item is implicitly given a high class of
service to eliminate wait times
 By implication, you can’t do this for every item. If all items are being expedited
then none are being expedited – its just non-deterministic chaos
Ask “When do you need to start [my item] in order to guarantee it is
ready when I’d like to receive it or when I need it?”
 Start times can be determined and controlled
 Scheduling work items is something we control, wait times during flow cannot be
controlled without class of service policies and queuing discipline

Considering Probable Loss from Delay in Starting
impact
When we
need it
Zone of
possible
delay cost
If we
start
here
Commitment point
timeJan
10
Nov
11
To consider the best time to
start something we can
examine the probable
opportunity lost by
multiplying the lead time
probability distribution
function against the Delivery
Delay Cost function.
By sliding the lead time
distribution across the
Delivery Delay Cost we can
compare the Probable Delay
Costs for a delay in starting
Delay Cost
Function

A typical lead time distribution function

Filter for Expedite requests

Filter for Fixed Date requests

Filter for Standard class requests

Filter for Intangible class requests

Using classes of service enables us to hack the probability distribution

What if everything was Standard class?*
i.e. No classes of service, treat all work homogeneously

Predictability versus Risk Trade
Because cost of delay risk isn’t
homogeneous, we introduce
classes of service.
We trade the overall range in
lead time, and general
predictability for greater
predictability of items with a
high cost of delay.
Where cost of delay is
homogeneous a single class of
service is preferred.

Now consider Fixed Date class of service
impact
When we
need it
Now
we can
start
here
Commitment point
timeJan
10
Dec
01
By introducing a Fixed
Delivery Date class of service
and filtering the Lead Time
probability distribution
function (PDF) just for Fixed
Date items, we significantly
narrow our risk.
We can defer starting until 1st
December & have close to
100% confidence of on-time
delivery
Delay Cost
Function
Anticipated delivery

#2 - Dependency Management

Dependency Management
Another area of inherent uncertainty
Costly in time and money to solve deterministically
Often deterministic approaches fail to resolve all dependencies and
result in anxiety and rushed re-planning when discovered late
As a reaction the desire is often to double-down, spend more time and
money on better analysis to improve dependency detection and inform
more accurate planning
This should be a red flag!

Cost of Delay informs Dependency Management
When the cost of delay is small or there is sufficient time to start early
then there is no need to manage dependencies explicitly. Let them
emerge and manage them dynamically
Where the cost of delay is greater introduce a dynamic reservation
system using different classes of service to reserve capacity on
dependent services

Reservation systems
First reported by Sami Honkonen, “Scheduling Work in a Kanban” November 2011
http://www.samihonkonen.com/wp-content/uploads/2011/11/scheduling-work-in-kanban.pdf

Dynamic Reservation & Classes of Service
Based on variability of service delivery throughput
1. Guaranteed – up to the minimum delivery rate
2. Reserved (not guaranteed) – minimum to mean delivery
rate
3. Stand-by – mean to maximum delivery rate
Reservation Classes & Kanban
1. Guaranteed = 6/week
2. Reserved = 4/week
3. Standby = 6/week

Dependency discovery
Dependency discovery is a request for information
Dependency discovery should happen upstream and be required for a
“definition of ready”
Providing information is a service
We should track dependency discovery requests as work item types, if the
level of effort required is more than a few minutes and becomes intrusive for
one or more people on the service delivery side
Dependency discovery requests (like many requests for information, e.g.
estimates) can be disruptive (and speculative) demand
We should treat dependency discovery like estimates: don’t do it unless you
really need to; if you need to then control the disruptive effect through time
slicing or resource/service delivery isolation

Classes of Service for Reservation Systems
We typically associate classes of service with service delivery
and the queuing discipline of tickets flowing through Kanban
boards
We can use classes of service for reservations in scheduling
systems. For example, you can hold a “stand by” reservation
for a “first class” air ticket. Different classes of services for the
reservation versus the actual flight
Use risk profiling to determine whether you care about delay
from dependency risk
 E.g. if we have a low cost of delay why would we bother to explicitly
manage for dependencies which may cause delay
Determine a class of service which directs policy on how (or if)
you will manage dependencies for an item and how a
reservation will be made
 In which time slot should we make a reservation and which class of
service (guaranteed/reserved/stand-by) is appropriate

Class 1 No Dependency Management
Calling Service
Called Service
We Don’t Care!
No WIP limits
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

Class 2 Tail Risk Mitigation. Reserved Capacity
Calling Service
Called Service
WIP limits
[5]
[2]
We wish to mitigate
the tail risk in the
customer facing lead
time by insuring
dependency delivery
is predictable &
reliable as a
consequence of
reserved capacity on
the called service

Class 3 Known Dependency. Informed Scheduling
Calling Service
Called Service
Reservation system
[5]
[2]
Filtered lead time
“Reserved” Class
Booking
Dependency
Analysis
Determine the
dependency
exists, make a
reservation for it
to insure
capacity on the
called service
when we need it!

Class 4 Known dependency. Specific Scheduling
Calling Service
Called Service
Reservation system
“Reserved”
“Guaranteed” Class
Booking
“Defn of Ready”
requires
confirmed
booking on
called service
We want a high
confidence in the
start time for
customer lead
time. We take no
risk on dependent
capacity becoming
available

Class 5 No margin for error
Calling Service
Called Service
“Guaranteed”
“Guaranteed” Class
Booking
“Defn of Ready”
requires
confirmed
“Guaranteed”
booking on
called service
No margin for
error!
We want 100%
confidence in the
start time for
customer lead
time and no risk
on dependent
capacity
availability

Multiple Reservations
Cost of delay (and other risk assessment) can be
used to establish, optimal start, and whether earlier
or later is preferred if optimal isn’t available
Make multiple bookings at lower classes of service
“reserved”, or “standby” for the same item.
If it shows up early and capacity is available start it,
cancel its other reservations
“Guaranteed”
“Reserved”
“Stand by” 3 bookings for same ticket

Conclusions

What other uses can you
find for classes of service?
Every time you feel the pull of the Dark
Side, the desire to produce deterministic
plans based on speculation, you should
think “How can Class of Service help
me?”

Classes of Service in Kanban
- The Sonic Screwdriver of Kanban Coaches

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 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.”

…
Acknowledgements

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

2016 Essential Kanban Condensed

Classes of Service - the "sonic screwdriver" of Kanban Coaching

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de David Anderson

Mais de David Anderson (20)

Último

Último (20)

Classes of Service - the "sonic screwdriver" of Kanban Coaching

Notas do Editor