Chapter 5. Work in process

This chapter covers

• Introducing the concept of work in process (WIP)
• The effects of a lot of work in process
• How to limit work in process

Work in process (WIP) is a phrase that you’ll hear a lot in the kanban community or when reading about Lean. WIP seems to be something that you don’t want or at least want as little of as possible, so you often hear kanban aficionados talking about “limiting” WIP.

This chapter will help you to understand what WIP is, what could happen if you allow a lot of WIP in your process, and, finally, some ways to help you to limit work in process.

5.1. Understanding work in process

In this section, we’ll dissect the concept called work in process. First let’s talk a bit about the abbreviation WIP and how it can be interpreted. WIP has at least two different meanings:

Work in progress

Work in process

Both of these meanings are widely used in the Lean literature. We happened to pick up “in process” from the literature we read as we learned about Lean and kanban. Throughout this book we’re using work in process, but you can exchange it for in progress if you like.

5.1.1. What is work in process?

Work in process means all the work that you have going on right now. That includes work you’re actively working on right now, work items waiting to be verified or deployed, and also the work sitting in your inbox that you haven’t started yet: all the unfinished things you need to do in order to deliver value to the end customer.

Work in process and lead time

Limiting WIP is one of the core kanban principles. It doesn’t mean you should do less work, but that you should do less work at the same time. Limiting your WIP will help you complete more work in total more quickly.

If you remember, back in the introduction we played a little game with the Kanbaneros—Pass the Pennies (see chapter 13 for details on how to run the game). The objective of this game was to show how different amounts of WIP affect your lead time, the time it takes for an item to go through your complete process. When the Kanbaneros were asked to flip 20 coins each before continuing, the total lead time was high; the WIP was 20 items at this stage. When the WIP was lowered, or limited, first to five (each worker flipped five coins and passed them on) and then to one (each worker flipped one coin and passed it on), the lead time went down—way down. The simple game showed you that the bigger the batches, the more WIP you take on, and the longer lead times will be.

A Word from the Coach

If you want some more concrete examples of what a lot of WIP can mean before moving on, we can give you one from when we were writing this book. At one point we grew impatient and started to write a lot of chapters simultaneously, before finishing the ones we were working on. We had about eight chapters going at the same time, and some of them were closing in on being done. We then decided to restructure the table of contents and ended up moving a lot of stuff around. That change was considerably harder to do, took more time, and caused more pain with a WIP of eight chapters than, for example, two chapters.

This relationship between WIP and lead time has been expressed as a law in mathematics—in queuing theory, to be more precise. It’s called Little’s law; let’s take a closer look at it.

Little’s law

When talking about limiting WIP, Little’s law often comes up. The law is a mathematical proof by John D.C. Little that says that the more things you have going at the same time, the longer each thing will take. It’s a formula that looks like this:

As always, the first time you see something like that, the correct response is “Eh ... what?!” If you’re anything like us, it didn’t make you go “Aha!” Let’s throw in some real numbers and see if that makes it clearer.

Imagine that that your team takes on 12 items for a month and works on them all at the same time, resulting in a WIP of 12 items. They also typically finish 12 items per month, giving them a throughput of 12 per month. It’s now trivial to calculate the cycle time for each item: 1 month.

Let’s do an experiment and—without changing anything about the way people work, the number of people on the team, or the work items—work with six items at the same time. That gives you a WIP of 6, still a throughput rate of 12 per month, and a cycle time of half a month. Wow! That’s quite an improvement just by doing less stuff at the same time; don’t you agree?

For completeness—the reverse is also true. Double the number of items you work on, and the cycle time is doubled to a whopping two months. This is provided that the other conditions (way of working, item size, people on the team, and so on) remain the same.

By handling fewer items at the same item (or limiting your WIP), you’re lowering the cycle time and moving stuff faster through the process—without changing anything else! You can probably do it now and have your work items flow much faster through your workflow. This in turn gives you feedback faster and helps you to learn about your process faster, which in turn gives you an opportunity to improve your process to move even more quickly.

Warning

Did you notice the small “probably” there? If your WIP is already pretty low, chances are you can’t lower it and expect the other variables in Little’s equation to stay stable. It might prove difficult to parallelize the work and have two people working on a task with the same efficiency. Decreasing WIP can have a negative impact on the average completion rate.

This isn’t necessarily a bad thing; in fact, it’s one of the strengths of kanban, because it will pose an improvement challenge. What do you have to change in your way of working to keep up your completion rate, even though you lower the amount of WIP? You can read more about this in section 11.1.2.

You now know a little about the concept of work in process and the theory of why you want to limit it. Let’s be a little more concrete and take a look at how WIP can manifest itself in the software development industry.

5.1.2. What is work in process for software development?

In chapter 1, the coaches helped Team Kanbaneros understand what their WIP was. WIP in Lean manufacturing is obvious because it often manifests itself physically: items piling up in front of a machine waiting to be processed or finished items on the floor waiting to be moved to the next step in the processing chain. Once you learn that it can have a negative impact on your work, it’s pretty easy to spot, because it often involves physical things.

WIP in knowledge work isn’t visual, and this is the driving force behind wanting to visualize work, to make work apparent and obvious where it previously wasn’t. This is one of the main reasons to create boards and stickies that show your work items and their status, as described in chapter 3. The work is there even if you don’t use a board; you just don’t see it as clearly.

But there’s more to WIP than the number of items you’re working on at the same time. Considering only the number of things you’re doing at the same time is a simplification. In this section, we’ll look at a couple of ways that WIP can manifest itself in the world of software development.^[1]

¹ See Mary and Tom Poppendieck, Implementing Lean Software Development (Addison Wesley Professional, 2006, http://amzn.com/0321437381), for more on this.

Specifications not being implemented yet

If you think about it, specifications have a “best-before” date. You could say that they rot if they’re left lying around.

Imagine that today you write a specification, and then you leave it. What are the odds that anyone could pick it up in six months and start coding from it? Even after only two months, there’s only a slim chance. Things in the business environment change, and the system for which the specification was written has probably also changed during the waiting time. At the very least, you have to go through the specification again to be sure it’s still valid.

A specification that is written and lying around waiting to be implemented is work in your process.

Code that isn’t integrated

Continuing along a stereotypical development process, the next thing that might increase your WIP is implemented code that you haven’t checked in and integrated with other people’s code yet. That’s also WIP, because you don’t know how much work there is still to do before you’re done with the work item.

If you’ve ever heard the phrase “It works on my computer,” you know what we mean. If you haven’t yet integrated the code with other people’s work, you still don’t know if it works at all. It works on your computer, with your settings, and in your environment.

Checking in and integrating your code often is a good way to not accumulate loads of integration work and to get quick feedback on the quality of the work you have done so far.

Untested code

Untested code is another way that WIP manifests itself in software development. To write code without having a quick way of finding out if it works or not is an excellent way to build up a stock of unfinished work.

Automated testing is one way to handle this problem. By using automated unit testing or test-driven development (TDD), you get quick feedback that you’re not introducing defects into the existing software. By doing automated acceptance testing or specification by example, you get feedback that you’re building the right application.

A Word from the Coach

Test-driven development (TDD) is a design and development practice in which you start by writing a small test for the code you’re about to write. It’s a micro-specification for the next little chunk of code you need to fulfill your task. As a side effect of working this way, you get a suite of test cases for all of your code. TDD is all about developing things right!

Another Word from the Coach

Specification by example is also known as behavior-driven development (BDD) and is a powerful way to, in essence, write your specifications as executable test cases. Specification by example is about communication and making sure everyone understands each other. Doing this badly, in our experience, takes a lot of time, because you then have to go back and forth and anchor the information around the feature to build. By using concrete examples early in the process, as you specify the functionality, you increase the likelihood that everyone means the same thing when you talk about the feature. In essence, specification by example is all about developing the right thing.

Code not in production

Finally, code that has been developed and tested but has not been taken into production is also WIP. You still have some work to do, and you still don’t know if the feature is functioning or if it will have a bad effect on other parts of your system. Above all, it’s not yet providing any value to the user—it’s still WIP.

If you think about it for a while, code in production might also be WIP. The work isn’t necessarily “done” just because it’s in production. Having the code in production, working, isn’t what matters—it’s how the users receive it, whether they benefit from it, and whether your software accomplished the (business) impact that you intended. If the user behavior isn’t affected, are you really done?

We have now examined what WIP is and how it manifests itself in our industry. Let’s dive in and look into the effects of too much WIP.

5.2. Effects of too much WIP

You might now think, well, a lot of work in process is a bad thing, I know. But how bad can it be? What happens if you have too much WIP? This section examines the answer in detail. It’s demoralizing reading, but keep your head high. You already know how to tackle this: limit your WIP!

5.2.1. Context switching

If you were Adam in the preceding cartoon, do you think you’d have to struggle to remember what you were doing when you came back? You probably would, right? This happens due to something often referred to as context switching.

Context switching was originally a concept from computing that describes how the computer stores and retrieves state for one process as it switches to another. This is the basis of multitasking several processes on one CPU. The feeling of “trying to get back to whatever I was doing” is the same thing, but for humans. When switching between several tasks, you need to set up in your mind the “state” of the task you were doing earlier. Think of it as human context switching.

You can compare this with the setup time for a machine in a factory. If the machine is rigged to produce Model A, it will take some time to readjust it to produce Model B. It’s then easy to understand that if every other piece is alternating between Model A and Model B, a lot of time will be lost due to setup.

That’s exactly what you experience when doing context switching in knowledge work. You lose time and focus for every task you’re trying to keep in your head at the same time.

One study^[2] showed that as much as 10% of your working time per project is lost to context switching. This means if you’re running two things at once, you have only 40% of your available working time per project to spend. With five tasks going at the same time, you have only 5% per project left.

² Gerald Weinberg’s book Quality Software Management: Systems Thinking (Dorset House, 1991, http://amzn.com/0932633226) is often referenced as the source of these numbers, although we haven’t been able to find them there. But Weinberg has confirmed that he’s the source in private correspondence with us.

Interestingly, another study also showed that context switching represented a 10-point drop in IQ. That’s more than twice the number found in studies on the impact of smoking marijuana (!). So if you have to choose between the two, you know what to do.^[3]

³ We want to be clear that the last part was meant as a joke. We wouldn’t want anyone to think that we’re proselytizing for using marijuana. Marcus, a member of the Salvation Army, particularly wants to underline this. The study is no joke, though: “‘Infomania’ worse than marijuana,” BBC News, http://mng.bz/HjcX.

What can you do, then? These projects and tasks are part of your WIP—the WIP for you. And by now you know what to do with WIP: limit it! Keep it to a minimum. If you have to keep several tasks going, at least try to have as few as possible at once. Try to complete one before starting another. Doing this will help you avoid context switching and complete each task more quickly (according to Little’s law).

Now you know something about the problem with context switching in our type of work. Let’s continue and take a look at another of the problems that a lot of WIP causes: more work.

5.2.2. Delay causes extra work

Imagine that you happen to introduce a bug in the application you’re writing. If you’re notified about it immediately, within minutes, it’s simple to fix, and nothing bad will have happened.

Now consider the same situation, but suppose it takes two months before somebody finds the bug and notifies you. It’s now considerably more work to fix the bug. You first have to remember what the feature is, what you did about it, and how to fix it. Then you might have to set up the system in the state it was in at the time to be able to reproduce the bug. Finally, the rest of the system might well have changed since then, making the bug much harder and more complicated to fix. And that is only considering you and your situation. You might have to involve others to be able to reproduce the defect (testers, system admins, or DBAs to set up the system in the correct state, for example).^[4]

⁴ At one client, Marcus had a meeting cut 30 minutes short because the other person had to read up on a bug they were about to discuss in the next meeting. “I filed it one and a half years ago” was the understandable reason for her need to go and read up on what she wrote back then.

All this extra work is caused because of the delay from the time you introduced the bug until when you were notified of its existence and could do something about it. You get more work (in process) due to the delay itself.

This problem boils down to the feedback loop being longer. Not only does a lot of work going on at the same time make each item go more slowly, but feedback on how each work item was received and behaves in production takes a longer time to get, too.

And that is a bad thing.

Feedback is an essential part of every agile process. Feedback is the creator of knowledge. It tells you about the quality of your work and the quality of your workflow. What works? What should you change? What shouldn’t you change?

The more quickly you can get feedback, the more quickly you can change a bad process into a slightly better one. So you want to fail fast if there are any problems. Delayed feedback makes it difficult to connect the effect to its cause, making learning very difficult or even impossible.

As you’ve seen, higher WIP causes feedback to become slower and slower. And the slow feedback itself causes even more work to be created, which causes even higher WIP, which prolongs the feedback loop, and ... well, you see where this is heading, don’t you? By lowering your WIP, you can stay on top of this problem and get feedback quickly on the small work items that move rapidly through the complete workflow.

But more WIP, longer lead times, and prolonged feedback loops: are those such as big deal? Yes, and the next few sections will show you examples of how they can haunt you.

5.2.3. Increased risk

With more work going on at the same time, you’re increasing risk. This has to do with not being able to change quickly and hence be more sensitive to changes in the world around you.

For example, let’s say that you have a process with long lead times. If your customer requests a change in a feature, it will take a long time to build and take into production. During that time, the feature may become obsolete, or a competitor may pick up that request and implement it first.

An example of such a feature could be integration with social platforms such as Twitter and Facebook. Many online services now give you the ability to log in using credentials from these platforms. If you have a long lead time, say a year, someone else might have already created a copy of your service with the social media integration in place.

Other places where the ability to change fast is important are within technology, as well as in the environment in which your company operates (trends, laws, and other regulations, for example). If you can’t change fast and get new features or changes to your customers fast, you stand the risk of losing relevance for your customers, your service becoming obsolete, or even being outmaneuvered by someone else.

5.2.4. More overhead

A really nasty thing about a lot of WIP is that more work will be created from the need to coordinate all that work. It’s a vicious circle that quickly can spin out of control and in which you end up only doing coordination. This resembles the situations we described in section 5.2.2, in which we talked about delays creating more work. The delay we talk about here is that you have longer lead times with a lot of WIP.

Imagine that you’re taking part in three different projects at once. Not only does that mean a lot of context switching for you, but those involved in the three projects will also likely ask you to do reporting, time tracking, and planning for all three projects. Because you’re moving in and out of the projects, you probably need to do a lot of hand-overs and coordination, too. Much of this extra work is created because you’re doing several projects at the same time. If you were assigned one project only, you wouldn’t be asked to do a lot of the tasks required to coordinate your work among three projects.

This kind of situation often occurs in organizations with a strong focus on using “resources”^[5] to the full. If you instead have a focus on keeping lead time short for the things you produce and smoothly flowing items to the customer, a lot of these extra tasks will be considered wasteful, and you will strive to eliminate them.

⁵ Often the word resource means people in these organizations, too.

A Word from the Coach

We have both worked as contractors for quite some time. In this business, time reporting is of the essence, because that is our product: as contractors, we’re billing the customer for hours. Without fail, the time-reporting system in contracting companies is typically a mess, is complained about, and takes a lot of time to use. More often than not, you’ll hear this at any contracting firm: “So who should we bill for the time it takes me to do the time reporting?”

At Marcus’s employer, Aptitud, he’s tried to resolve the problem of this wasted time by reporting deviations from a norm. If he’s assigned to one project for 60% of his time, and that’s the number of hours he worked for that client, he does nothing and Aptitud will bill the client for 60% of his time. If he, for some reason, is two hours short of 60%, then he reports those two hours as a deviation.

5.2.5. Lower quality

If you’re a developer, the quality of your code may suffer from long lead times. This has to do with the prolonged feedback loop that lasts from the moment you write code until you know how it was received and how it functions in production.

Imagine that you happen to cause a bug to be introduced; you assumed that the customer had one name, but there should be both a first and a last name. The error passes unnoticed, because all the customers in your system up to that point were companies and used a single name field.

Then one day, several months later, your first “private” customer tries to log in and gets upset because he can’t enter his first and last names as he is used to doing. Correcting this bug isn’t easy; a lot of code that depends on customers having a single name property has already been written. You have worked around the bug without noticing.

Scott Bellware^[6] once compared this situation to introducing a hernia in the system, and he illustrated that with the preceding pictures. At the outset, your system is nice and tidy. When you introduce the bug, one line gets distorted. Until you’re informed about the bug, you’ll work around the problem, creating bad code that compensates for the bug in the system. It’s not until you fix it that you can get back on track and have a well-aligned system again.

⁶ See Scott Bellware, “Design Flaws, Hernias, and Anemic Quality,” February 9, 2009, http://mng.bz/f2x1, for more.

Compare that situation to one in which you’re immediately notified about the bug you introduced and are able to fix it within hours of writing it. No hernia, no fuss: simple and quick.

The difference between these two situations is lead time: lead time from when you introduced the bug until you’re informed of it. During that time, your code has suffered in quality, which means fixing the bug will take longer and will be more difficult.

5.2.6. Decreased motivation

Long lead times can decrease the motivation of your team, too. It’s not hard to see why, because stuff ending up in another queue isn’t a motivation booster.

Take Daphne in the preceding cartoon. She has been slaving away on that feature that Adam has asked her to complete by today. It even took her part of the night, but she knew that it needed to be ready for Adam. He demanded it, because the last three times he had to wait on her. Making Adam happy this time provided the sense of urgency (or motivation) that Daphne needed to go the extra mile and finish the item today.

But when Daphne arrived in the morning, she found out that the item was the last in a long array of work items that needed to be tested. Her motivation to deliver on time took a severe hit.

In this example, it was Adam who had a lot of things going on at the same time. Because of that, he couldn’t give Daphne feedback on her work until two weeks later. That in turn resulted in Daphne’s motivation dropping; and when Adam finally came back, she couldn’t have cared less about the testing result. He was interrupting her at that point, because she had moved on to other work.

What should they do about that? Well, herein lies the real reason to strive for lower WIP and hence shorter lead times. It will expose problems^[7] for you: problems that, if you try to fix them, will make your flow even faster, even smoother. Sadly, kanban doesn’t say much about how to fix these problems. You have to find out for yourself by seizing one unrealized improvement opportunity at a time. We have devoted chapter 10 to practices that can help you find and implement process improvements.

⁷ Sorry—“unrealized improvement opportunities” is much better.

5.3. Summary

This chapter talked about work in process and specifically discussed limiting WIP in order to get shorter lead times:

• WIP is a common abbreviation, and it has at least two meanings: work in progress and work in process. We prefer work in process and use that throughout the book.
• Little’s law tells us with mathematical certainty that the more WIP, the longer the cycle time for each work item will be. You should limit the WIP to get faster flow and shorter lead times.
• WIP can take many forms, and we looked at some common ones in software development:
  • Specifications that haven’t been implemented yet
  • Non-integrated code that “works on my computer”
  • Untested code, which may or may not live up to your standards
  • Code not in production, which sits and wait for the next release
• Problems and bad things can follow from having a lot of WIP:
  • More context switching
  • Prolonged feedback loop, which in turn causes extra work for you
• And we mentioned some ways that WIP can manifest itself:
  • Increased risk
  • More overhead
  • Lower quality
  • Less motivation

You now have solid knowledge of what work in process is and why too much of it is a bad thing, and you have a theoretical understanding of what to do about too much WIP. The next chapter will be much more practical, and you’ll start setting WIP limits for your team.