The concept of Work in Progress (WIP) is at the core of Kanban. WIP is work that has entered the production process, but is not yet complete. WIP includes all partially finished work whether it is currently being worked on or not. Generally in IT projects work that is not complete has little or no value. Therefore, to maximize the value delivered, teams need to move units of work from started to completed with the least amount of delay. Minimizing the amount of work in progress delivers functionality and reduces the risk.
Minimizing WIP to the capacity of the process increases a team’s ability to complete work. All processes have a natural capacity where a piece of work can be started and completed without stopping and starting to work on another piece of work. Software development processes are not significantly different. However, Kaban’s emphasis on minimizing WIP is generally at odds with most waterfall software development methodologies that have dominated IT for the last generation. In the waterfall model we would do all of the analysis, usually a requirement at a time. We would build a backlog of requirements and package them in a requirements document and then pass them through a phase gate to the next stage. In this example we have a lot of WIP and a lot of WIP that is spending sitting around being inventory. For a waterfall project to generate value the whole project must be complete. Kanban limits the work in progress to only those items that can be actively be worked at once. In a manufacturing context, limiting WIP reduces the amount of capital tied up in production. In IT projects, limiting WIP gets units of work completed so they can delivered and generate value.
Limiting WIP is an effective mechanism to limit risk. Even if work is not immediately released, the completed units of work will generate feedback which increases the probability that work that is ultimately delivered will meet the customer’s needs. Shorter cycles and single-minded focus on working software help teams avoid the two biggest risks most projects face—that of eventually delivering nothing (failing) or delivering too late.
In the classic book by Tom DeMarco and Tim Lister Waltzing with Bears, risk was grouped into five categories:
- Intrinsic Schedule Flaws – The flaw is that the project schedule is incorrect.
- Specification Breakdowns – The problem is caused by not knowing all of the requirements or that project requirements change over the life of the project.
- Scope Creep – Requirements are added without control.
- Personnel Loss – The problem of key individuals leaving negatively impact the delivery of the overall project.
- Productivity Variance – The problem that productivity variations go unnoticed impacting delivery.
Limiting WIP specifically address the first two of these categories (Kanban helps with all five) by delivering work and generating feedback. While managing work in progress requires changing how work is packaged and managed therefore is difficult. The benefits in delivering value and reducing risk is undeniable.