…you find out which processes aren’t wearing swim trunks.
WIP stands for “Work in Process.”
When you start work, it becomes WIP. When you ship work, it stops being WIP. Another name for WIP is “inventory.”
In software, an idea becomes WIP as early as when you enter it into a work tracker. Yeah, your backlog is WIP. You’ve spent time on it, but it hasn’t delivered any value to your customer.
Most software orgs seem optimized for high levels of WIP, which will fight against you delivering on-time and with high quality.
WIP tends to go up wherever you have a handoff because most people, upon becoming blocked while waiting for something, reach for doing more work. We want to be “doing something.”
People being blocked is an important signal that something is wrong with the flow of work in your value stream. If you’re getting this signal, it tells, “oh, look, something that needs fixing.”
If you hide the signal by taking on more inventory, you’re undercutting your efforts in two ways:
- Again, more WIP means higher lead time, which indicates lower quality, and
- If you don’t get the signal that something’s wrong, you can’t know to act on it.
Suppose I were in charge at your organization, and I told you and everyone else, “you’re only allowed to work on one thing. If you start something, you don’t stop it until you finish it.” What’s your visceral reaction?
Once you’re done calling me insane and accept this new reality, you might adjust the way you work to accommodate it by:
- Working in smaller batches, so that you’re more available to incoming requests
- Level loading with downstream work centers to avoid waiting
- Shifting things like testing and peer review left to avoid queueing
- Cross-training team members so that certain skills aren’t a bottleneck
If you do that, I’m almost certain your throughput will go up. Morale too, probably.
But if you keep your work high, you’ll never even notice there’s a problem. Everyone will remain busy, but you still won’t ship things.
