Many Kanban teams use classes of service to help model their workflow. We’re going to talk about how they work, where they are valuable and why you should avoid them wherever you can.
What are classes of service?
A class of service shares much in common with a work item type. They both tend to have unique policies which affect how we prioritize and perform work on the item. Where they are different is that a work item type is constant throughout the life of the work item while a class of service can be applied or removed at any time.
For example, if a work item comes in that we define as being a bug then it will stay a bug through its entire lifecycle (assuming that we didn’t make a mistake and categorize it incorrectly). Bug is then it’s work item type and is constant. Imagine now that two days after the bug arrives, we start digging into it and discover that it has critical side effects that need to be addressed immediately. Now we might apply a class of service to apply a different set of policies to that work. A day after that, imagine that we find a work around for that bug so it’s no longer important enough to be considered expedited so we remove the expedited class of service. Throughout the entire process, it remained a bug while the expedited class of service got added and then removed as we learned more.
Although it’s not universally true, it’s extremely common for a class of service to affect the priority that we give to work and this is where we get into trouble.
Common examples
There are two classes of service that almost all teams feel are necessary so we’ll call them out here. There are certainly many others that could be defined.
Expedited
Expedited work is defined as having a higher priority than other work. It’s like an ambulance that is traveling down a street. The defined policy for an ambulance (usually dictated by law) is that all other vehicles must move to the side to make room for it. This allows the ambulance to quickly get to it’s destination, regardless of how busy the roads might be.
The most common policies for this class of service are that any expedited work must be done before any non-expedited work and that expedited work is allowed to increase WIP limits by some defined amount. Usually it’s allowed to increase limits by one. This is to ensure that even if all columns are full, expedited work is allowed to pass through.
Date driven
Date driven work are things that have a due date attached. The work item arrived today and must be done in three days time.
The common policy is that we review each date driven item at least once a day to see if the date is currently in jeopardy. If it is then the item is treated as expedited until the next time we review it allowing the work to flow faster than other items. If the date is not in jeopardy then we treat it as any other typical work.
Why they should be avoided
The common characteristic of classes of service is that certain work becomes more important than other work. While this benefits the work that’s been given the priority boost, it plays havoc with the rest of the system.
Imagine that ambulance driving down the street. Every other car has now had to pull over to the side and will take longer to complete its journey.
The impact is small when there’s only one ambulance but now imagine what traffic would look like if every third vehicle was an ambulance? The rest of traffic would be so slow as to be unusable. All predictability of those other cars would be gone. When will you get to your destination? There is no way to know.
Any piece of expedited work will slow the entire system and make the system less predictable. The more expedited work, the greater the impact it will have. Expedited work also has a very real impact on stress levels of the team, the more expedited work a team has the higher their stress levels and the less effectively they are able to work (See Waste: Psychological Distress for more info). If we can eliminate the need for this work we will be better off in almost every way.
How can we reduce the need for classes of service?
Many teams think they have no control over the amount of expedited work and that’s almost never true. There will always be some things that we can’t control. If all of production goes down, that’s clearly a higher priority than anything else we might do. Still, the need for many types of expedited work can be significantly reduced.
Quality-Driven
When we find that a particular type of expedited item is coming through regularly then we can look at root causes for that and address them. Is one particular part of the code failing regularly? Let’s focus on improving that.
Unnecessary Dates
Many times dates are assigned to items unnecessarily. Dates may be added by managers in a misguided attempt to motivate the team, often having the opposite effect. Any time a date is added to a work item ensure there is a valid business reason for that date. If we miss this date then we’ll miss a key business opportunity.
Poor Planning
Too often items with real dates are just started too late. Do some planning and start those items early enough that they never need to be expedited.
Systemic Issues
Finally, often the most effective way of reducing the need for classes of service is to reduce the cycle times of work in your system. If you can lower cycle times, and therefore the forecasted completion date for new work, the need for special rules around how to prioritize certain classes of service often go away. It may be enough to simply ensure that piece of work is started next rather than having it flow around already started work.
Conclusion
There are certainly times when expedited work is a necessity but when it’s happening often enough that we’ve created dedicated classes of service for it then we should consider whether we can improve our workflow or our quality to reduce the need for those policies in future work.
Any time we expedite one item, we reduce the effectiveness and predictability of the entire system. That’s a heavy cost to pay for something that could have been avoided with a bit of planning.