Classes of Service in Kanban: what are they?
This is my understanding of classes of service from the Kanban method.
Classes of Service
Standard/As soon as possible (ASAP)
This is normal work that needs to be done and should be done as quickly as possible.
Fixed Date Work
This is work that has to be done by a particular deadline. Deadline does not include somebody’s grandmother’s birthday or daughter’s birthday. A real deadline, not an arbitrary deadline.
A real deadline means something bad will happen on that date, ie there’s a significant increase in cost. Perhaps we get a penalty or we miss a payment opportunity. The fixed date is real.
Expedite
This is something that is really urgent. It is hurting us right now, and if we do not deal with this immediately, we could have major problems. For example, an outage with your product or service.
Intangible
This is when we have an item that maybe we do not know for sure when we are going to get this increase in cost. But there is a long-term thing that if we do not deal with it, it will bite us in the backside at some point.
Sometimes we do know the date. For example, there is a piece of software that is going to go out of support at a particular date, so it is going to cost millions to get it supported after that date if you want to pay the supplier to give special support after that date.
But more often than not, it is an unknown date when that hockey stick, increasing cost will eventually occur. It could even be as a result of shortcuts we took in the past, where the product or service is now so fragile that maybe it is in danger of collapsing at some point. So there could be some hockey stick increase in costs.
Culture eats strategy for breakfast and how to deal with urgent requests
There is a saying, “culture eats strategy for breakfast”.
While mathematically and from a flow point of view, it is a really bad idea to have different priorities for items on a definition of workflow. This is because you are giving preference to some items over others, causing some items to age more than others, eventually leading to unpredictable cycle times. These elongating cycle times eventually result in reduced throughput.
If the culture of your organization dictates that expedited items need to be dealt with urgently, maybe that is something you need to do. However, I put it to you that there is a better way of dealing with really urgent requests.
What you can simply do is… rather than having different classes of service for different types of work, if something urgent occurs, we just record a breach in our Work-In-Progress (“WIP”) limit.
Don’t increase your WIP just to account for an emergency
It is not a good idea to increase our WIP limit just to take account of an emergency because by doing that, we are actually increasing our WIP as standard.
It is better to breach your WIP limits by exception. That is the direction the Kanban Guide would be going in, where you would, instead of having special increased WIP limits, (like an expedite line for example), you would record a breach when an urgent item occurs.
I once heard a humorous way to deal with this: when someone comes to you with an urgent item, come back with two sleeping bags, and to the confused customer say, “here is your sleeping bag and this is my one”. The customer most likely will say, “what are you doing, why are you giving me a sleeping bag?”
“Well, you said this is urgent, so that is your sleeping bag and this is mine, because we’re not going home until we fix this, right?”
Ohhhhh, it’s not that urgent.
I guess what I am trying to emphasize is the point of “how urgent is that urgent request?”
Fixed Date Items: In terms of fixed date items, you could just write the fixed date on the card, so we all understand that there is a fixed date on the item.
Intangible: Why I really appreciate this class of service where the culture is about utilization of people
If there is one class of service that I appreciate, it is Intangible. This is my personal opinion.
In a context in the past where the culture was about utilization of people (of course in Kanban we do not want to keep everybody busy, we want to optimize flow, and after we optimize flow we then try to improve the utilization of our people, but in an optimized way, just in the same way we don’t want to fill the motorway with cars), what I did as a coping strategy was I asked the team to fill their board with intangible work, work that needed to be done on the long term.
This was a bit cynical of me, but it was a nice coping strategy for the team. You put in the normal work, for example, and the various priorities and so on.
The power of having intangible work on the Kanban Board
By having intangible work on the Kanban board, we are starting to work on that long-term work and so maybe in 18 months when the hockey stick increase in cost eventually might occur, perhaps we have already dealt with that.
If we do not bring in the intangible work, if people are kept utilized, it is likely that in 18 months, that intangible work could become an urgent request. The genius of actually putting intangible work on a board in a context where there is a high utilization mindset is the intangible work is the contingency, it is the slack on your board. This is because we know that if something urgent does occur, or there is a fixed date item, that we want to get those across the line perhaps.
In order to do that, we sacrifice the intangible items that are already on the board. So the intangible items will have terrible cycle times. Perhaps we can isolate the cycle times for those separately, so we can separate the signal from the noise.
We do need to be cognizant that intangible work can eventually bite us in the backside and by actually having intangible work in the system, we can ensure that it is done by that time and we will not have that emergency in 18 months.
On classes of service in general
So about classes of service in general, culture eats strategy for breakfast.
If you go to an airport and there is no first-class section for people to go through faster security, maybe there will be an uproar. From a flow point of view, it is better if everybody goes through the same security queue. For everybody, it will be faster because we have people deployed to help people with their security and the work is evenly distributed.
If you do use classes of service, the Kanban Guide does not prevent you from doing that. In fact, Kanban Guide is designed to support, well at least to not lack support for other Kanban and Flow approaches.
We were deliberate about not trying to break other approaches, so by people starting with Kanban Guide, they can, for example, upgrade to Kanban Method, hopefully, or to Tame Flow or some other Flow approach, Flow System etc.
Work item age is the most important measure
Kanban Guide does not prevent you from using classes of service, it is just from a flow point of view, work item age is the most important measure and you need to be cognizant of the impact of not managing relative work item age. Relative work item age tends to go out of control when we reprioritize items that are already in progress.
The Kanban guide view would be that you can use whatever prioritization technique to start work, including classes of service. But once the work starts, you should just finish it. Why? We do not know how valuable the item is until we have finished. You will have some trade-off decisions.
I had some teams in a large bank, for example, where they did use classes of service, but they put a ceiling on it.
There was one leader who impressed me one day.
We had:
- expedite lane,
- intangible,
- fixed date,
and you can either do it by lane, or you can do it by different colors, or legends, or whatever. They happened to have lanes. The leader said “yeah, we are going to use classes of service, but we are going to put a ceiling on the work. If any item has not moved for four days, we are going to focus on that today”.
By doing this, he was combining classes of service with a ceiling on the work item age. Therefore, he was preventing work item age from going out of control. It still worsens your flow, but I thought it was a nice compromise. It is something that maybe you can consider.
Concluding Remarks
Classes of service are an option in Kanban Guide. It is just not something that is part of Kanban Guide.
It is part of what is recommended in other approaches, and you are not prevented from using it.
Thank you.