Twas the night of Thanksgiving,
And all through the house
All the dishes were ready
The food was set out
And while we were eating,
Just out of the blue,
It hit: the newsletter!!
Oh, what do we do?!
Our oldest child does a lot of the artwork and graphics for B2T4U, our monthly newsletter. While cleaning up after Thanksgiving dinner, they asked me about the theme for the December newsletter so they could get a head start on the banner design. Pretty sure I looked like this:
I think we’ve all had that moment. The one where we realize, “this is due right now, and I’ve got nothin’.” So how did I get myself into that position? I mean, really, I should know better, right? I did some thinking and realized that I’d actually diagnosed my problem earlier in the week during a conversation with another team member who is updating some of our courseware. Our conversation went something like this:
If you’re familiar with Kanban practices, you know that one of them is “Limit WIP”. So what’s WIP? Why is it important to limit it? How can you actually accomplish this in the real world? Let’s see if we can answer those questions.
What is WIP?
WIP stands for “Work in Progress”. It refers to the number of work items you have started to work on but have not completed. If you’ve done anything work on the item at all, no matter how little, the item is considered part of your WIP.
Limit WIP
Why does the amount of work in progress matter? While it seems like a good idea to get started on things as soon as they land on our desk, it’s actually counterproductive. Let’s look at two key reasons for this.
Reason #1
Multitasking is a myth – and trying to multitask leads to errors
People talk a lot about multitasking. Some people even take pride in it – “I’m great at juggling lots of tasks simultaneously!” But the very real fact is that human beings don’t multitask. Instead, we task switch. Think about it. Let’s say you’re working on documenting two processes. You don’t actually work on both of them at the same time. You flip back and forth between the two of them. Task switching is inherently inefficient because we lose productivity every time we change context. Envision what happens when you stop documenting Process A and start documenting Process B. You have to set aside all the information for Process A. Then you have to find and access the information for Process B. If you’re like me, you have to spend a little time re-orienting yourself to where you were when you left off the last time you worked on Process B. All of this takes time, and it’s time we wouldn’t have to invest if we worked on one process at a time.
In addition, task switching is an opportunity for errors to occur. Look back at my message exchange above. In the midst of all my task switching I got lost and made a mistake. Fortunately I caught it quickly…but what if I hadn’t? What if my teammate had spent hours inserting graphics into the wrong class? What an enormous waste of time that would have been.
Reason #2
Too much WIP lengthens lead time and delays delivery of value
“Lead time” refers to the amount of time that elapses from the moment I begin working on an item until the moment I finish it. When we have lots of items in process all at once, we end up with long lead times. Let me illustrate that with a simple example. Let’s say we have 5 work items in our backlog, each of which will take us a day to complete. Let’s also say that we haven’t started working on any of them.
If I work on a single item at a time, each item is started and finished in a single day. So on the first day, I move an item from “To Do” to “In Progress”:
Without a solid understanding of these three vastly different “customers”, it would be impossible to develop a meaningful customer journey map. How do we gain that kind of understanding? One really helpful tool is the persona. A persona is a fictional character developed to help us better understand, empathize with, and create valuable solutions for our customers. Done right they can:
At the end of the day, I’ll have one work item completed:
End of Day 1:
And at the end of the next four days, I’ll complete one more work item each day. Since each item is started and completed in a single day, we say its lead time is one day.
End of Day 2
End of Day 3
End of Day 4
End of Day 5
On the other hand, let’s say I start working on all five of them at once and I split my time evenly across them. At the end of day 1, I have five items in progress and no work done:
In fact, nothing is finished and delivered to the organization until the fifth day.
End of Day 2
End of Day 3
End of Day 4
End of Day 5
What this means is that none of our work is delivering value to the organization until the fifth day. Contrast this with the first scenario, where each day a portion of the work is finished and can start delivering value.
Limiting WIP is not the same as minimizing WIP. By showing this example, I don’t mean to imply that working on one item at a time is the right answer. For most of us, that would be completely impractical.
It takes a little experimenting to find a balance that works for you. I’ve learned lately, for example, that I can’t work on half a dozen different class updates at once. I need to stick to two or three at the most. That gives me enough work to do so that I can stay busy if I’m waiting on something from someone else without giving me so much to do that I lose track of where I am and make mistakes.
Visualizing and Managing WIP
Did you notice that I snuck a Kanban board into the last topic? It’s a great tool that can be used to visualize and manage the amount of WIP you have. Let’s quickly review the basics of a Kanban board. In its simplest form, a Kanban board shows work we need to do (your backlog), work in progress (your WIP), and work that is done. Maybe like me you’re trying to coordinate all the things that need to be done for an upcoming holiday. A simple board might look like this:
For a team effort, you can visually depict which tasks are assigned to certain individuals. Some teams will add a sticker or other visual cue to a card; other teams may use lanes for each team member:
Adding WIP limits to your Kanban board ensures that everyone knows how many tasks you can take on at once. It also helps you visually verify that you’re sticking to those limits.
Making it Real
This all sounds great, right? But we all know that it only takes “super urgent truly an emergency gotta have it right now!!!” task from the boss and all this is out the window. Or is it?
Earlier I showed you a Kanban board that uses lanes to track the work that’s assigned to various team members. You can also use lanes to show what are called “classes of service”. Classes of service are different types of work that our teams are asked to do. David Anderson, a thought leader in the application of Kanban practices and principles, suggests four different classes of service: Expedite, Fixed Delivery Date, Standard, and Intangible. Items are placed into these lanes on the board, and each lane has a WIP limit:
Expedite is for critical and top priority items that require immediate handling. They preempt any other work the team is doing. Examples of items that would fall in this class are critical production issues, network outages, and hardware failures. While there is typically a WIP limit of 1 for this category, the limit can be raised if a number of truly critical issues occur at once. When this happens, it may be necessary to reduce the work in one or more of the other classes of service, and teams should swarm the items so they can clear them as quickly as possible and return to normal operations.
The fixed delivery date class of service is for work items where there is a significant cost of delay if the work is not delivered on a specific date. Contractual or regulatory obligations are often placed in this class; seasonal business items may be placed here as well.
Standard items typically represent the bulk of a team’s work. While these items are important, there is typically a lower cost of delay than is seen with fixed delivery date or expedite items.
Intangible items are the “nice to haves”. They’re useful but not urgent. Keep in mind that if left in this category for too long, things that start out as intangible can eventually become critical.
These classes of service aren’t set in stone; they can be adapted to your needs. It is recommended that teams limit themselves to no more than 6 classes of service to keep their Kanban system from becoming overly complex. A common capacity allocation gives 20% of a team’s overall WIP limit to fixed delivery date items, 50% to standard items, and 30% to intangible items. Expedite items typically take a team over its normal WIP limit.
Keep Calm and Kanban On!
A phrase that’s used a lot in teaching Kanban is, “Stop starting, and start finishing.” Easier said than done, I know! But since New Year’s is right around the corner, maybe it’s a good resolution for some of us to try – including me. Witness this text exchange from today:
<sigh> Seems like I have a ways to go in defending my WIP limits!
All the best,
–K.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
