Mike Lyons explains why multitasking kills productivity: task switching increases lead time. Limit work in progress by doubling your team size minus one, then adjust with data. WIP limits expose systemic problems like bad handoffs and missing environments that need fixing.
Double the number of people in that workflow step, then subtract one (e.g., 3 people → (3×2)-1 = 5 WIP).
I used to proudly tell people that I was an excellent multitasker, great at multitasking. My resume used to say it as well. Well, it doesn't anymore. Because I've come to realize, and maybe you have too, that multitasking is a myth. The truth is we really can only task switch, and we do that at varying speeds and varying costs. But one thing we do know for sure is that it's easier to start things than it is to finish things. And the more things we have in flight at any given time, the longer all those things take to complete. So multitasking is really the enemy of getting things done. It slows us down, it slows our teams down, it increases our lead time. Another way to think about it is this. The more work in progress items we have in our system, the longer our lead times will be. And so our second practice of Kanban is limit work in progress. Too much work in progress becomes visible when demand outstrips capacity. It's sort of like when there's too many cars on the highway. You know, maybe you've experienced this. Of course you leave work at same time everybody else leaves work and everybody's on the freeway. And too many cars, well, it creates traffic and your lead time increases the longer it takes for you to get home or wherever you're going. So why would this matter to you? As a Scrum Master, the primary reason it matters to you is that it increases your lead times. Lead time again is that idea from when a piece of work enters your team, probably when you commit to it at Sprint planning to when you're done with it. But hopefully you're done with it before the sprint ends. By limiting wip, it will actually decrease the amount of time it takes to get work done. Scrum masters, I know what kind of pressure you're under. You're under constant pressure to get more work done. This act of limiting WIP alone can help you do that. Some other reasons you should be concerned about work in progress. Delayed delivery of value, increased costs, decreased quality, conflicting priorities, irritable staff and poor morale. And since we're operating in a pull based system, that is that work can only move when there's a signal, a Kanban for work to be pulled into the next workflow step. It's those WIP limits that help smooth out that flow as opposed to the work piling up in front of the workflow step. I get asked a lot, how do we begin to put these WIP limits in place? A good place to start is to take the number of people in each workflow step and double it and then subtract one. So for example, if you have three developers, you might start by doubling it, that's six. And then reduce it by one for five. So WIP limit of five. I used to just say double the number of people, but that didn't provide the forcing function that forces people to collaborate when they're stuck. And so go ahead and double the number, reduce it by one. Now, WIP limits, once you try them, they can be adjusted. They should be adjusted. Use your retrospectives scrum masters to ask questions. Questions, are our whip limits working? But here's the thing. We don't want to increase them or decrease them just because someone wants us to do more work or they think like if we increase it we'll get more done. That's not the case. That's again, that's just like putting more cars on the highway. Many highways have on ramp lights. That is the the light turns green and one car can go on the highway. Different freeways have have different rules though. The light turns green and two cars can go. Maybe you've seen that these are WIP limiters for getting cars on the highway. But the Department of Transportation, they don't make those decisions all willy nilly. This one's going to have two cars. That one's going to like. They don't just make that up because someone said we want more cars on the highway. They use the data and the traffic patterns to judge what the whip limit should be. And you need to do the same thing, use data. So decrease your whip limit and then watch your lead time. Did that reduction reduce your lead time or did it increase your lead? What did it do? We've got to pay attention to when we adjust and close the loop on the system so that we're using data to make these decisions. Now one additional reason, and this is kind of the added and not often talked about benefit of WIP limits is that when we get out of this multitasking madness, what tends to happen is the real problems in the system surface. So what are some underlying system problems that this might reveal? Things like dependencies on other teams waiting for approvals, not having enough detail before we start, lack of lower level environments or poor quality work being passed downstream. And when we fix those like lower level system issues in our processes and combine it with focused work, eliminating multitasking work begins to really flow through our system.
Feel the flow, Happy, feel it. It's circular. It's like a carousel. You pay the quarter, you get on the horse. It goes up and down and around circular circle with the music, the flow.
An important thing to remember here is that when you limit wip, that in itself won't actually smooth out the flow of work. No, it's how we respond to the WIP limits. When you apply WIP limits, you're going to immediately see problems surface. Some people on the team will all of a sudden have no work to do, their column is blocked, and some people on the team will be overburdened. You may find yourself with developers that are underutilized. Well, could they go work on test and sort of move those test cards forward? So WIP limits will reveal where there's problems. You still have to go solve the problems. Limiting WIP is not intuitive, so it's going to be a little tough at first. Just remember, WIP limits are your friend and they're the key to getting the most work done. So now it's your turn. Take the board you just created from our last lesson and begin to apply WIP limits based on the current number of people in each workflow step. Just. Just write it down at the top of the column. If you have a tool, just add it to your tool. Make sure you're applying WIP limits to your current board that you created from the last lesson. And so there you have our second practice of Kanban limit work in progress.
