Scheduling work in Kanban with Dynamic Reservation Systems

Reservation systems have been observed in Kanban implementations  since 2008. They are used immediately upstream of a delivery kanban  system, to indicate the desired start date of the request for work (a  work item).

2-phase commitment

Reservation systems facilitate 2-phase or asynchronous commitment  between the requestor and the delivery kanban system (also known as a  service or workflow). 2-phase commitment can be useful when it is  difficult to get the requestors, the customers or businesspeople,  together with the delivery organization, at the same time, or, when it  is possible to determine that something is needed, without a specific  commitment to when it is needed or when it should be started. If  scheduling can be separated from the determination of need (¨yes, we  want it¨ or ¨no, we don´t need it¨) then a 2-phase commitment is useful.  It enables business people or customers to make decisions about what,  independent of the delivery organization that controls the scheduling of  when.

2 types of reservation systems

We have observed two ways to implement 2-phase commitment, and hence  reservation systems, the first is a simple queue, as observed in the  Posit Science case study (2007-2009) and used in our Kanban System  Improvement (KSI) training, and the second is a schedule or calendar,  first reported in a blog by Sami Honkonen in 2011.

While queues are useful and can provide an additional lead time for  signaling other long lead time activities such as marketing and public  relations, they are relatively simple and quite boring. For example, the  Posit Science case study features a 10 place FIFO (first in, first out)  queue, and the delivery rate of their kanban system is approximately 1  item per week. Hence, the ¨Top 10¨ queue provides 10 weeks of advanced  first-phase commitment. Something in the queue is required and its  approximate start date is determined by its place in the queue and the  delivery rate of the kanban system.

However, it is schedules or calendars with bookings to start a  request item on a given date that is much more interesting and powerful.  The remainder of this article discusses the utility of a booking  system, particularly for dependency management. For clarity, the terms ¨booking¨ and ¨reservation¨ are used interchangeably in this article.

Implementing a Reservation System

A reservation system is typically implemented as a calendar using  weeks of the year and visually displayed above or to the left of a  kanban board. Each ticket in the calendar represents a request to start  an item on that date – in other words, a request to pull the item from  the upstream backlog or pool of options, or ready buffer, on the date  indicated. Note that it is a request to start, the action over which we  have control, and not a request for delivery on that date. Items with  hard delivery dates are usually handled with the Fixed Date class of  service, and the requested start date would be reversed out from the  desired delivery date, based on anticipated lead time.

The number of slots per week should be equivalent to the average  delivery rate (or throughput) from the kanban system for the same period  e.g. 1 week. We know that delivery rates tend to exhibit a Gaussian  probability distribution and hence it is reasonable to use an average.  We do not want to take bookings for more than the average throughput of  the system as this would overburden the system and cause problems and  delays.

However, we do not want to throw away one of the great advantages of a  kanban system – deferred commitment. We do not want the use of a  booking system to schedule work in advance to encourage a lot of ¨big  planning upfront¨ and early commitment when that isn´t appropriate. So,  our booking system needs to be flexible. It needs to be able to cope  with late-breaking news, new arrivals, last-minute reservations, and  important and urgent work that must take precedence over existing  bookings. We call this adaptation to our reservation system, a dynamic  reservation system.

Implementing a Dynamic Reservation System

To cope with uncertainty such as the arrival of last-minute requests,  or late-breaking requests that are both urgent and critical, we need to  introduce classes of reservation – we need to treat reservations  differently based on their risk. To adequately hedge our risks, we  should allocate capacity for different classes of risk. Classes of the  reservation should generally reflect the cost of delay and indicate the  preference a request is given for starting on the requested date.

The image in Figure 12.12 taken from our book Kanban Maturity Model,  illustrates how to calculate the allocation of classes of booking using  real throughput data from a business in Germany. In this example, the  average throughput is 20 work items per week, and the range is 8 to 32.  The minimum throughput seen in recent history is 8 items per week. This  allows us to offer 3 classes of booking with the following capacity each  week…

• Guaranteed class of reservation – guaranteed to start on this date with a capacity of 8.
• Preferred – will start if capacity is available. If not started may be bumped to  guaranteed for the next or a subsequent replenishment, with a capacity  of 6.
• Standby – indicates preferred date but  the item will compete for available capacity on merit. If unselected, a  preferred reservation may be made for a later date, using the remaining  capacity of 6.

These 3 classes of reservation seem adequate to handle most  circumstances when coupled with 4 classes of service once an item is  started and pulled into the kanban system. The goal is to put some  adequate expectations around customer experienced lead times, delivery  predictability while preserving the flexibility to cope with items of  varying urgency and varying degrees of notice for a request before its  start date. The reservation system should enable us to avoid too much  unwarranted and undesirable delay before an item is started while  enabling us to have the confidence to defer commitment and not start  items needlessly early.

Where to implement a Dynamic Reservation System

We recommend that such reservation systems are implemented for  internal shared services, platform services, and anything that handles  irrefutable demand (or dependent demand generated by a request already  committed to a customer). They are extremely useful for managing  dependencies and any form of irrefutable demand that cannot be rejected,  but the demand can be shaped, and the flow smoothed out by carefully  scheduling ¨must do¨ items.

Reservation systems can also be implemented on external  customer-facing services. They are likely to be useful when coping with  low or broken trust relationships. They are particularly useful for  genuine fixed delivery date demand where commitment and start date are  deferred until close to the last responsible moment. However, they will  always be more effective after internal capabilities have been improved  first.

Conclusions

Reservation systems enable us to take better control of when items  will start, they are not a guarantee of delivery. To improve delivery  timing and predictability, it is always necessary to improve the  predictability of the kanban system lead time and to have a thin-tailed  lead time distribution. Reservation systems simply give us another tool,  another practice to utilize, to enable better customer satisfaction and fit-for-purpose service delivery.