Can you afford not to limit work in progress?

Do your stand-ups sound something like this?

Joe Developer: I started on that script, worked on it for a while and then I switched over to that web app i’ve been working on for the last few days. I got blocked on that so I started up that template they’re waiting on.

Jane Developer: I worked on that UI component library but then got pulled into a fire drill about something the PM needed right then. Today I’m going to finish the fire drill item, work on a defect someone asked me if I could sneak in really quick (its only 1hr of work) and then I’ll get back to the UI component.

… [repeat, repeat, repeat]…

These same developers, not to mention their manager and their manager’s managers, (oh, and don’t forget the people waiting on the value they’re not delivering) get really frustrated over the fact that “everything around here takes forever to get done.”

Well, don’t fret. You are not alone. By far. This situation exists in countless working teams across the world. Replace the development jargon with reports and other types of work and you’ve multiplied your fellow sympathizers exponentially around the world.

If you think everyday is like floating around in streams of consciousness you need to stop the insanity. The satisfaction of instant gratification is our worst enemy. Its so easy to start something, but not always easy to finish something so we start, start, start. In addition, you’re bombarded with these questions: “When can you start this piece of work?” and “Can you fit this in?” Starting is valuable, right? Its showing progress and progress is what’s important. Am I wrong?

Well, you tell me. When is the last time your customers got value out of what you started? Do you feel calmer and calmer as you start more and more new things, increasing the number of things on your plate? I think of it like a dieter with a plate of doughnuts. Starting that work feels really good until you realize you’ve just increased the time it will take to reach your real goals.

Context Switching

What is truly important is finishing things so value can be delivered. So much time is wasted and so much value lost by splitting focus — starting new work. When work is started it should be carried through to completion and not interrupted. When interruptions happen, in thought work especially, we incur time costs due to context switching. There are natural ramp down and ramp up “transactions” that happen between value delivery of tasks.  Normally these occur when you finish one task and start another. When these transactions are forced to be executed during tasks due to interruption, extra time is added to the overall time of finishing said tasks.

Normal example:

Task A: 2 hours
+ 10m mental ramp down
+ 10m mental ramp up
+ Task B: 30m
+ 10m mental ramp down
+ 10m mental ramp up
+ Task C: 2 hours
5 hours 10 minutes total time spent for 3 tasks without context switching

Context switching example:

Task A 1 hour, then INTERRUPTION!
+ 10m mental ramp down
+ 10m mental ramp up
+ Task Z: 30m INTERRUPTION
+ 10m mental ramp down
+ 10m mental ramp up
+ Task A: 1 hour to complete
+  10m mental ramp down
+ 10m mental ramp up
+ Task B: 2 hours
5 hours + 30 minutes total time spent for same three tasks with context switching.

The true cost

I know what you’re thinking… 10 minutes ramp down and ramp up? Preposterous! Well, I can really see that in my team with switching apps, synching repositories, committing changes, etc. It really doesn’t matter what the exact time length is for those activities, what matters is they happen and they consume time. If you can see from the examples above that there are extra activities when context switching, then you can agree that you incur more time spent when you suffer interruptions. The 20 minute time difference in my example may not seem like much but its extremely costly at scale.

20m waste * avg #of interruptions in a week * ppl in organization = $$

Real example:
Let’s look at my current dev team and make a guess that each developer averages 10 interruptions in a week — that’s 2 a day so not too out of line. That would be: 20m of waste per interruption * 10 interruptions in a week = 200 minutes of waste per person per week. I have eight people in my team so 200m * 8 = 1600 minutes of waste per week on my team. 1600m/60m in an hour = 26 hours. Take a pretty reasonable $80 out of thin air for a developer hourly cost.

When you do the math, I have over $2000 of waste on my team each week just due to “multitasking.” I could do a lot with $2000 a week.

But, wait! We haven’t even begun to dive into the opportunity cost. $2000/wk is the actual amount of money I’m paying for interruptions. What is the opportunity cost of those 26 hours/wk? In other words, what is the value my company could have been accruing for work we could have delivered in those wasted 26 hours? That is the equivalent of a part-time employee (3d/wk)! If you add the opportunity cost together with the actual cost you get much closer to the true cost of interruptions. Some day you might want to consider the cost of attrition triggers but we’ll leave that alone for now.

What to do?

First, understand your true cost of interruptions. I’ve given you a formula. With some observation and salary info you can come up with a dollar amount. Share this cost with your team. Your team is going to be a front-line of defense to avoid this cost. They need to understand the cost of their choices and when to push back on potentially wasteful requests. Its not just a management thing.

Then, implement a Kanban system to manage work-in-progress and control interruptions. Make explicit policies about interrupting work. Is it never allowed? Is it allowed when the cost of delay of an item is more than the cost of interruption?

Finally, keep revising. If you see nothing to improve, you’re likely just not looking hard enough 🙂

The real question

I hope that you leave this blog post pondering what I consider to be the real question. Can you afford not to limit WIP?

If you’re wondering why a blogger with the handle EverydayKanban has a team that’s not limiting WIP you’re probably not alone. I’m relatively new to the company and spent quite a lot of time observing and orienting (you know, the OODA loop), trying hard not to derail the projects in flight when I arrived, as well as working with a standard scrum model as is the practice. We will be layering a Kanban process over our scrum process starting Monday and it will be enlightening to share the results and how our processes morph from there!