Work-in-process (WIP) is not just the work we’re working on, but anything that’s been started and not completed. This means once we’ve started on an MBI until it is released it is WIP. Managing WIP is a a recurring process. Once we have sequenced our work in the proper order we can now allocate our capacity to the truly most important items. We should not start projects that adversely affect more important ones merely to “utilize” our people. Managing WIP is essential. We are not trying to achieve the “one-piece flow” that Lean-Manufacturing does. Rather we are trying to avoid working on too many things at one time.
The symptoms for doing so are:
It is clear that if a team works on two things at the same time when they could be focusing on just one the delivery of both will be delayed. But what’s not so clear is what happens to the work because of the now, interleaving nature of the work. That is, working on one project hen another and then coming back to the first. These delays in workflow, feedback and using information obtained literally induces additional work. This is why a one week interruptions delays what people are working on by more than a week. The week spent on the interrupting work causes additional work to be done because the effort interrupted cannot just be picked up again without a cost.
Some people attempt to manage work-in-process via WIP limits. It’s usually easier and more effective to create a focus on finishing. Completion exists at many levels: tasks, stories, features, and MBIs.
We don’t recommend using work in process limits. They are not really needed and complicate things. In the early part of the value stream WIP can be managed just by having teams pull work only when they are ready. Otherwise, the focus on finishing can manage WIP. Too many Kanban implementations don’t focus enough on collaboration and cross-functional teams. In this case they sometimes overcompensate by having WIP limits in place.