In most Kanban systems established, classes of service refer to an assessment of impact to the business. While I personally like this approach, often this assessment technique doesn’t fit well for some teams or organizational issues. It may also not be very informative for some work items being managed. I have always believed in using Kanban, and particularly its associated metrics, for identifying areas to improve. Sometimes we need abilities to slice by similar items as far as impact, but that may have other degrees in which they vary. So I’d like to present a few other styles for identifying these. I’ll start at a team level and move upwards towards something more organizational wide.
Maintenance Activities
I often seem to find teams performing maintenance activities (upgrades, defect/bug fixes, small to large enhancements, etc.) struggling to find ways of understanding the metrics that will be useful to them. While an Expedite class of service, with its own identifiable swimlane and corresponding WIP limit, is invaluable, a standard class of service is not when the timeframe or scope tends to skew the metrics results. I want to be able to predict when an activity may be done with some confidence. If I lump all of the activities into one standard class of service, the larger items will skew the average lead time to a higher number than my smaller activities and my variability will be very high.
A concrete example is an ERP upgrade versus an important (but perhaps not critical enough to go into the Expedite column) bug fix. The ERP upgrade may fix numerous (just as) important bugs as well. Upgrades in ERPs often can’t be broken into apples to apples comparisons as the tasks are entirely different though the lifecycle that may be managed through the Kanban process may be identical. Additionally, the items that must be completed for the definition of done (which become cumulative entry/exit criteria along my columns) may also be different.
BTW, these types of items may be tracked within a higher level Kanban and not necessarily a team based one…
Portfolio Items
Definitely moving a level or two upward, if I have portfolio items that need to follow an identical process, but may have varying entry/exit criteria or varying typical timelines may also be worth tracking as separate classes of service though each may be more or less equally important to the business (i.e. close to the same prioritization in the backlog). Here’s some examples: reogranizing a particular function, redesigning a business process, implementing a new application (at the highest level). Each may follow a similar process of: Backlog -> Analyze -> Implement -> Measure Performance -> Done. The definition of done and timelines may be quite different on each of these items. Wouldn’t it be nice the next reorganization being proposed I understood how long my last set took in terms of average lead time and its variability so I can predictably give an answer to the board? I don’t want to skew my data with that for my last network upgrade.
One could argue that we could (or should) use separate Kanban boards for these, but I think this is less than useful. I can think of two reasons to have these on the same board.
- I want to understand how my organizational WIP of change affects cycle-time overall. This would be very difficult to do if these were spread across multiple boards. (This is not to say that each effort may not have its own more detailed board.)
- Also if I want to also think through alternatives approaches and compare cycle-times as a magnitude of cost (since often time is money) and benefit (time to market), having these on the same board makes this much easier. By tracking this information, I can use this information as input to my decision-making on which approach I may use. For example, if I can use it as input to analyze whether I redesign my current business process or automate the existing process. Knowing the cycle-time can become part of the analysis both in terms of cost and benefit
A Quick Analysis View
So how do we determine these different classes of service? Well I have already hinted at the dimensions that we will use. We’re going to basically categorize the work item types by time it takes to get them done (just a gut feel of time) and differences in the scope of definition of done, looking for vastly large differences. You can place these on a grid such as the one below.
So even items with a similar definition of done may have vastly different timelines, knowing this keeps us from skewing the data when we want like items. Additionally, not lumping things that have vastly different definitions of done (column(s) exit criteria) yet follow an identical process at the level we are looking at it can also be very helpful. The bottlenecks that may occur can be different; this also makes a useful distinction. Lastly, I can now view all of these dissimilar items on the same board and yet have a means of distinguishing them and their corresponding metrics.
When one is stuck on identifying classes of service, or the classes of service between the items appears meaningless, give this a shot and see if it helps. I’d be interested in other viewpoints.
Paul Boos' Nimblicious - Making Agility Tasty 
Hi Paul, Interesting grid axes…
Looks like a useful “blink” board!
Curious: Do you see the X axis, DoD scope, as an analog to complexity?
Pondering: How might we correlate this grid to some kind of CFD? (Cumulative Flow Diagram)
Thanks again for the perspectives!
LikeLiked by 1 person
Hi Ken,
I think the DoD Scope may correlate to complexity; I’m a little leery of saying that is fully true.
Let’s go to the example of improving say my company’s acquisition process to reduce the time it takes to get a contract awarded. So , the business outcome I should see is reduced lead time from contract need to contract award while still getting the right type of vendor in under the right contract. (The following may be an oversimplification, but I hope it shows the point.) Let’s stick with my high level (appropriate for executives) view on this implementation: Backlog -> Analyze -> Implement -> Measure Performance -> Done
I may have two high level different ways of doing that –
1. I could streamline the process which may change or eliminate the roles people play, the approvals and thresholds that play into those approvals, and the rules I impose on myself on how I interact with ‘vendors’. My high-level DoD may be the following:
– all roles changing or eliminated identified and job descriptions modified in HR
– people working in those roles counseled and/or terminated (laid off)
– policies and procedures updated and managers notified
– any notifications or announcements to my vendor ‘audience’ have been made
2. I could also implement a document assembly application (like Exari in case you are wondering what I mean) that allows me to capture my existing rules and processes and allows me to produce my RFP and finalized contract much more reliably in a shorter amount of time. My high level DoD for that may be the following:
– select appropriate software product
– install and test software product; customize/integrate as needed
– train personnel on usage
In this instance, it would be nice to look back at times where I have done similar work to understand both the average lead time and the variability for these two types of approaches to see which may allow me to get to the end faster as *one of my inputs* for selecting which approach or strategy I may use. How long have my HR-oriented changes taken compared to application implementations?
This is definitely an apples an orange comparison that would be useful for decision making.
The Y-Axis of time (as a gut-check) also correlate to complexity though. I’m not going to use this view of classes of service as analysis input in the same way. Here I am concerned mostly around prediction. Let’s use some software maintenance examples.
Suppose I have a patch to my database I want to install that touches a significant amount of security features. A separate issue may be a bug in my business logic I need to correct so I get the right result. Both may have the same DoD of ensuring code is completed, tested, deployed and the change stored in my source code repository, and any corresponding design, operations, and user documentation updated. The security patch may require more complex testing on potential impact and this complexity may drive it taking more time. The bug may be easily corrected and may require just a few updates to tests to ensure it is reliable (perhaps it was an edge-case that was unforeseen). The bug may take substantially less time. From a business perspective, both of these may be very important (say #s 1 & 2 in prioritization).
What I may be asked for both of these is the amount of time it will take to implement and deploy them. If I had these types of work both under a single standard class I may have a difficult time in predicting how long each would take. The short-term bugs would make my longer patch-type work look shorter on average and my bug fixes look longer. The variability would be much higher as a result, thus I would have a lower predictability. Tracking each of these as its own class of service would solve this problem as I could track lead time more easily for each type.
This is also an apples an orange comparison that would be useful for prediction.
For the grid to CFD ponder; most tools can allow you to filter by some form of class of service (or tag or type) to see only those relevant items, so this is a place where the various Kanban tools like LeanKit have an advantage. I would recommend for a physical board using different color stickies for each class of service and keeping a separate maintained, visible CFD for the classes of service that matter most for the type of work the organization does.
I hope the above clarifies my thoughts on this… Again thanks for the question!
LikeLike