Work In Process isn’t just code sitting in your editor. It’s any task that’s not done, done, done. In other words, if it hasn’t made it all the way through your software process, it’s still work in process.
WIP (Work In Process) is considered a problem for several reasons:
- WIP usually cannot be unit tested (and can rarely be integration or acceptance tested), which leads to uncertainty. If you can’t measure a process, you can’t improve it.
- Some source control systems don’t make it easy to commit some work and leave other work checked out. Even in stream-based systems like Accurev and ClearCase, it can be difficult to keep things straight. This prevents even more work from being integration and/or acceptance tested, compounding the problem.
- The more WIP a developer has on their plate, the more context they have to keep track of in their heads. While good Software Engineers often excel at multitasking, there are limits, and it’s often much later that a bit got dropped.
- It’s widely accepted that the sooner you find a bug, the easier and cheaper it is to fix, because there’s less code to look at, and it’s fresher in your head. The longer a task is in flight, the harder it can be to find issues with it.
- As the current iteration approaches its end date, WIP threatens to make the iteration run long, or leave work to be finished in the next one, if that’s even an option. Or even worse, rushed out the door with insufficient testing or documentation.
Of course you can’t completely eliminate work in process, because that would mean you’re not doing work 😉 There are ways of minimizing it though. It can be done with a formal process like Kanban, or by simply establishing that each person (yes, I’m talking about you too, QA) work on one task (or at least one story) at a time. Hopefully your project tracking system is able to make the problem evident and measurable. This is actually a selling point for the index-card-and-cork-board system; you can’t help but see the cards piling up in one of the squares.
If you want to read more on this subject, Matt Stine has a series of articles on DZone’s Agile section called The Seven Wastes of Software Development. The first article in the series is on this very subject. I found it very informative.