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

Email [email protected] Twitter @lki_dja Copyright Lean Kanban Inc.

Classes of Servicethe sonic screwdriver of the Kanban coach

Reductionist determinism is the “dark side,” resist it with

Classes of Service

David J. AndersonChairman, Lean Kanban Inc

Swift Kanban WebinarMay 2017

mailto:[email protected]


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 servicewith kanban limit per color

5 4 4 5 2 = 20 total

Allocation

10 = 50%

...

+1 = +5%

4 = 20%

6 = 30%

InputQueue In Prog DoneDoneIn Prog

DevelopmentAnalysis BuildReady Test

ReleaseReady



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



TestReady

Flow Efficiency

F

E

I

GD

GYPB

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

IdeasDev

Ready

5Ongoing

Development Testing

Done

3 35

UATReleaseReady

∞ ∞

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

Poolof

Ideas

F

E

I

Engin-eeringReady

Deploy-mentReady

GD

2 ∞Ongoing

Development Testing

Done Verification Acceptance8 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

Poolof

Ideas

F

E

I

Engin-eeringReady

Deploy-mentReady

GD

2 ∞

No Pull

Ongoing

Development Testing

Done Verification Acceptance3 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

InputBuffer

DevReady In Prog Done

BuildReady

Test ReleaseReady

Stage Prod.DoneIn Prog

DevelopmentAnalysis

Policies~~~~~~~ ~ ~ ~

Policies~~~~~~~ ~ ~ ~

Policies~~~~~~~ ~ ~ ~

Policies~~~~~~~ ~ ~ ~

Delayuntil 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

InputBuffer

DevReady In Prog Done

BuildReady

Test ReleaseReady

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

TestReady

Implications of low Flow Efficiency

F

E

I

GD

GYPB

DE MN

P1

AB

IdeasDev

Ready

5Ongoing

Development Testing

Done

3 35

UATReleaseReady

∞ ∞

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

timeJan10

Nov11

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

timeJan10

Dec01

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 2011http://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/week2. Reserved = 4/week3. Standby = 6/week



Dependency discovery

Dependency discovery is a request for informationDependency discovery should happen upstream and be required for a “definition of ready”Providing information is a serviceWe 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 sideDependency discovery requests (like many requests for information, e.g. estimates) can be disruptive (and speculative) demandWe 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 boardsWe 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 ServiceWIP 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” ClassBooking

DependencyAnalysis

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

“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” ClassBooking

“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



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



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



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



Reductionist deterministic planning is the way of the

Dark Side

A Jedi must embrace uncertainty

Learn to manage probabilistically, you must!



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

Leadership & Management

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