Software Work In Process

In my last post, I talked about tools for tracking Agile projects.  Whatever too you use, you have to know what to do with the information.  It’s not just about the project being ahead or behind schedule, it’s about using the information to improve the software development process and its implementation.  One optimization which has been part of many Agile schools from the beginning, back to the Toyota days, is minimizing work in process.  In fact, it’s the major focus of Kanban.

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.



  1. David:

    Good post.

    In manufacturing planning, obsolescence is discussed as an issue related to WIP. When a Bill of Materials changes, subcomponents in WIP need to be reworked or scrapped. The less WIP, the less rework. I wonder if there is an analogy here? For example, a partially completed task left for the next iteration could be obsoleted if the requirements change between iterations.


    1. Excellent point. Yes, there is a parallel in software. When you have work in process of any importance, you’ve committed to certain design decisions and implementations in that code. But since it’s not working and integrated yet, you don’t know whether it actually works yet. You still must abide by those design decisions in your other work. If integration and/or acceptance tests prove those designs unworkable, you need to reimplement them in your WIP, but you also need to change it in any other code you made based on those unproven designs.

      As an example, let’s say you’re adding some new component to the system. It’s taking a while, and others need to use it, so you create a stub implementation and check that in so others can access the API. If, as you flesh out the real code, that design won’t work and the API needs to change, now the users of your class need to change their code to. This multiplies the uncertainty.

      Thanks for commenting.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.