Beware the barrenness of a busy life.
—Socrates

1.1

TOO MUCH WORK-IN-PROGRESS (WIP)

On the roof of a building, Saturday, 9:00 a.m.

A man undertakes an item on his honey-do list (his to-do list, heavily influenced by his spouse), which includes dismantling the roof of an outbuilding. Over the years, this man’s list of things to do has included repairing everything from appliances to septic systems. He has buried power lines, felled ninety-foot-tall cedar trees, and built cabins and garages step-by-step from excavating foundations to installing flooring, heating, plumbing, electricity, and roofing.

Recently, he seismically retrofitted an unreinforced, hollow-tile foundation. I am this man’s assistant, which includes (but is by no means limited to) acting as tape measure holder, safety inspector, and demolition and cleanup crew. One day, while helping him tear down the rafters of an old, crumbling twenty-four-by-thirty-six foot outbuilding (I on the ground, he on the roof), I casually suggested that we build a sixteen-by-twenty-four-foot greenhouse on the back forty. From the top of the twenty-five-foot-tall rotting roof, my beloved husband looked at me incredulously and said, “Hon, can’t you see I’m busy up here?!”

The tech sector does not have a monopoly on too much work to do. Talented people everywhere receive long to-do lists. The problem for a spouse who can build or fix anything is that the other spouse provides them with a long list of things to do. And it’s hard for them to say no (unless they are atop a twenty-five-foot tall rotting roof).

We humans have a hard time saying no for a variety of reasons. Reason number one is because we like the person who asked us. The same holds true at the office. Because network engineer Sean gives me a heads up on work coming down the pipe that impacts me, I say he’s nice and am willing to help him out when he needs something. But Carlos! Carlos knew about this port change two weeks ago and is only just now telling me at 5 p.m. on Friday?! My mental narrative says, “I don’t really want to help you.”

There are five other main reasons people give when I ask them, “Why do you take on more work than you have the capacity to do?”

1. We are team players—“I don’t want to be the person who lets the team down.”
2. We fear humiliation—“I don’t want to be criticized or fired.” Yes is easier to say than no—especially to the boss. Refusing a manager’s request can be risky in some cultures.
3. We like new and shiny—It’s much more fun than doing the grunt work it takes to finish something complicated and unglamorous.
4. We don’t realize how big the request is until we start working on it—“Oh, no problem. I can get that done in just a couple of hours,” but the task takes much longer.
5. We like to please people.—“I say yes to most requests in general because I want to be liked, admired, respected. “

Vanessa Bohns, social psychologist and professor of management sciences at the University of Waterloo in Ontario says, “It comes down to this fundamental motivation we have to stay connected to other people. We don’t want to reject people. We don’t want people to think poorly of us…so we are really managing the impressions other people have of us.”1 On the flip side, we rarely realize the power we have over other people when we ask them to do something, especially if others worry about explicit or perceived positions of power.

In textbook terminology, too much work-in-progress (WIP) is when the demand on the team exceeds the capacity of the team—which is a rather boring way to say that our teams are drowning in work, often because their schedule is completely full. Every minute of the day is fully scheduled (or fully allocated to 100% resource utilization). The most talented have the longest lists. This equates to people doing their full-time job on top of everything else that is expected of them, such as troubleshooting environment issues (problems with the configuration of servers that prevent website functionality and other things from working right), hiring new team members, and completing merit reviews, to name just a few. Similar to how our digestion system lets us know when we’ve stuffed too much food down it, Thief Too Much WIP attacks us if we cram too many meetings into our day, leaving us unable to begin the day’s to-do list until 6:00 p.m.

Why Too Much WIP Matters

Too much WIP matters for a number of reasons. It can result in many issues, including delayed delivery of value, increased costs, decreased quality, conflicting priorities, and irritable staff, to name a few. When we start a new task before finishing an older task, our WIP goes up and things take longer to do. So does the potential loss from things taking too long to complete and being unable to realize the value of it sooner. We measure this with cycle time. Cycle time is the amount of elapsed time that a work item spends as work-in-progress. In addition, business value that could have been realized sooner gets delayed because of too much WIP. This is known as cost of delay. It’s a concept used to communicate value and urgency—a measure of the impact of time on the outcomes we want, such as customers buying our product this month instead of next month.

When you delay the delivery of a new feature because another request got bundled in with it, there’s a cost for the delay of that new feature. It could mean late feedback, less profit, or a missed sales lead opportunity. Your new feature gets hijacked on its way to your customer, and the more stuff you add, the longer the customer waits. If customers wait too long, they shop elsewhere. Once customers give up and move on, you lose. Maybe it was worth it—but do you really know?

In general and for the purposes of this book, I define customers in two flavors:

External customers: People outside your organization who buy or use your product or service. If they move on to greener pastures, you lose revenue—and you risk a less-than-favorable review on your company’s Facebook or Amazon page.

Internal customers: People inside your organization who ask you to do something or who consume your work. A Product Development team is a customer of the security engineer who detects vulnerabilities in the product or the platform it sits on. An employee is a customer of the manager who provides feedback. Internal customers impact WIP. For example, Help Desk WIP grows when the accounting admin gets locked out of his computer. Marketing team WIP grows when the technical evangelist adds a new conference to her tour. Platform Operations WIP grows when the VP of whatever hires a third-party vendor to build a new integration.

WIP is a leading indicator of cycle time. The more items that are worked on at the same time, the more doors open up that allow dependencies and interruptions to creep in. Trailing or lagging indicators are backward focused—they measure performance data already captured. Most metrics measured in technology and business, such as lead time (the elapsed time it takes to complete a request from the time it was first requested), cycle time, and throughput (the number of things completed over a period of time), are trailing indicators. That is, we don’t know how long certain things will take something until those things are completed.

There is a relationship between the amount of WIP and cycle time—it’s called Little’s Law, where the average cycle time for finishing tasks is calculated as the ratio between WIP and throughput. WIP is a primary factor in the equation. It’s obvious when you think about it—as soon as you get on a clogged freeway you know that your commute is going to take longer. For this reason, Thief Too Much WIP is the ringleader of all the other thieves.

You know Thief Too-Much-WIP is stealing time from you when:

Context switching is common: When computers context switch, the state of the process currently being executed is saved so that when it is rescheduled, the state can be restored to its correct spot. Because computers perform hundreds of context switches per second, it’s easy to believe that multiple tasks are performed in parallel, when in reality the central processing unit (CPU) is actually alternating or rotating between tasks at high speed. As Todd Watts writes in his blog post “Addressing the Detrimental Effects of Context Switching with DevOps,” the overhead incurred by a context switch, managing the process of storing and restoring the state, negatively impacts operating system (OS) and application performance.2 Because a context switch can involve changing a large amount of data, it can be one of the most costly operations in an OS.3

Just like computers, humans incur overhead when context switching between different tasks. Although with humans, the overhead is much higher. Data structures containing all the information registers and OS-specific data, along with the exact point of entry for where to resume the process, aren’t automatically rescheduled in the brain like they are in a CPU. Context switching in computers has a programmable flow to it.

The notion of flow in humans doesn’t happen when context switching is the norm. Flow is the concept of focused motivation. It’s charac-terized by complete absorption in what one does (energized focus). It’s an optimal state that results in high levels of productivity and satisfaction. To achieve flow is to be in the zone—that space where intrinsic motivation and creativity flourish.

To achieve flow, a focused concentration on the task at hand is necessary. This doesn’t happen when distractions, whether in the form of email, food, coworkers, or social media, interrupt us. When we are responsible for multiple things, such as maintaining production and delivering new features, we shift what we’re doing based on perceived priorities. By the time we get back to working on whatever we were doing before the interruption, we have to start all over again. Flow requires a “do not disturb” ethos.

Your customers wait for long periods of time: Flow also requires a level of efficiency. When it comes to flow efficiency, the length of time you keep your customer waiting is of prime consideration. If new projects are started before existing projects are finished, work piles up, requiring more resources and/or more people. It is inefficient from a customer perspective to prioritize starting new work over finishing the things you have already begun. If I’m writing a blog about kanban and the next step in the process is to have it edited by someone on the Marketing team, then beginning a new blog about DevOps before incorporating Marketing’s edits for the kanban blog means I’ll have to deal with a context switch when the editor gets back to me.

Quality suffers: Quality suffers from too much WIP. When I was at Corbis and took on the additional role of managing the new SAP basis team, I shot myself in the foot. I had to learn a complicated mainframe product while building a new team on top of continuing to do my original job. I hadn’t done anything with mainframes since my first job out of college seventeen years before, and I didn’t know anything about SAP. I didn’t take the time to learn it very well because I had all these other things that had to be done on my plate. The result was a predictable one in retrospect: Neither the team nor SAP nor my other responsibilities got adequate attention. This led to a poorly managed team and an irritated me.

Irritated staff: Context switching is irritating—you’re rarely left with enough time to do a good job, nor with sufficient space to master the task or skill. Harry F. Harlow, an American psychologist, says in Daniel Pink’s book Drive, “The joy is in the pursuit more than the realization. In the end, mastery attracts precisely because mastery eludes.”4 Mastery eludes because there is insufficient time to pursue something long enough and deep enough before being interrupted.

Interruptions thwart deep thinking. Sherlock Holmes thinks best when he goes to his “mind palace” in the BBC adaptation of Conan Doyle’s famous sleuth’s escapades.5 Using a mental technique called the method of loci (Latin for location), he travels to his memory bank, a sort of mental map where memories are deposited, to withdraw memories. But he needs an environment void of distractions and interruptions, and he gets quite cranky if others interfere with his mind palace. And with good cause—it’s downright irritating to be interrupted when deep in thought. Time thieves love the area of deep thought because, as David Rock relates in his book Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long, it can take up to twenty minutes to get back to that same thinking spot after an interruption.6

Someone asks you if you have five minutes and you say yes: All too often, when someone asks you, “Do you have five minutes?” and you say yes, you end up working late. It’s annoying and sometimes exhausting, and we do it to ourselves. Even though I teach this stuff, I fall into this trap too. In our defense, we do get more endorphins from saying yes7—enough that even grouchy people want to say yes. However, it’s not productive to say yes all the time, nor is it sustainable to consistently work evenings and weekends. The power of kanban gives you the freedom to finish work.

Kanban is Japanese for signal card—a card that, very simply, signals your availability to do some work. When you pull a card from the backlog onto the in-progress area of your kanban board, you commit to being available to do the work that the card represents.

Figure 2. Prep Implement Feedback Board

The number of cards under the in-progress area reveals the amount of WIP on the kanban board. The board in Figure 2 shows a WIP of four. WIP limits are what make kanban a pull system. When a card is finished, it signals available capacity and causes another card to be pulled into In Progress. Work flows across the board based on the WIP limits and pull policies. If WIP limits are set appropriately, the system cannot become overloaded. The WIP limit is what allows you to say, “No, there is no capacity to take on more work right now.” Think of reducing WIP not as limiting but as liberating. The right amount of WIP is what enables us to maintain a healthy amount of work.

When you say to your pal, “Yes, I’ll do that,” you have just authorized and prioritized “that” request over all the other requests in the backlog. Dan Weatbrook, Tableau WebOps Manager, calls this “born-in-doing”—a way of cutting in line, if you will.8 It’s a thief stealing time away from previous requests and is one reason why requests in the backlog take so long (and sometimes never make it) to the In Progress state.

These elements of too much WIP crop up across all the thieves. Thief Too Much WIP is the ringleader, and the other thieves steal ideas from this relentless troublemaker. We will get into more details on how the thieves interact with each other a bit later. For now, let’s take stock of what we’ve covered so far about our thieving ringleader and move on to thief number two, Thief Unknown Dependencies.