Work-in-process or WIP refers to how many different tasks your team has started but not completed. High WIP levels are correlated with long lead times and low quality.
You’ll often hear people say that you need to reduce WIP to go faster, but it isn’t quite that simple.
Work is slow for some reason. Your team advances on something and then gets stuck. Maybe they’re waiting for a code review, or maybe they’re waiting for manual testing.
So while they’re waiting they pick up some other work and start doing. They feel “efficient” even though work isn’t getting completed.
Taking on additional WIP masks the pain of being blocked. With the pain masked, the cause of the pain doesn’t get addressed.
Reducing WIP, to single-piece flow if you can manage, is useful because it stops hiding that pain. But if all you do is reduce the WIP, you keep the pain, and it feels acute. People tend to not enjoy prolonged periods of acute pain.
So do reduce that WIP, but also empower your teams to fix the things that block them. Do that consistently, and you’ll see quality increase, lead times decrease, and you’ll have a competitive advantage in retaining your talent.
