Scrum and Kanban are a great combination. With this insight more and more Scrum Teams become aware of terms and phrases used in Kanban. Like ‘WIP’.
When I have used this acronym in the past I have read it as ‘work in progress’. In his book ‘The Goal’ Eliyahu M. Goldratt consequently uses ‘work in process’. I realized this but didn’t give it much thought.
This week, though, I discussed WIP with a colleague and we talked about the difference of ‘work in progress’ and ‘work in process’. And only then I realized that the two phrases mean something completely different.
Work in Progress
progress (n): a forward or onward movement (as to an objective or to a goal)
progress (v): 1. to move forward or 2. to develop to a higher, better, or more advanced stage
So, progress is good. It describes movement towards a goal and implies improvement. This is what we actually try to achieve in our daily work. We want to make progress towards our Sprint Goals or product vision. We want to improve our way of working together. And we want to make progress in our own understanding of the problem domain and the solutions we create.
If we read WIP as ‘work in progress’ why would we want to limit it? Wouldn’t it be great if we can make more progress by having more work? This is where we should read the acronym in a different way.
Work in Process
process (n): 1. something going on or 2. a series of actions or operations conducing to an end
process (n): to subject to or handle through an established usually routine set of procedures
Process is more fuzzy. If something is going on or we follow a series of actions towards an end something crucial is missing: the direction and the clear goal.
In a business context process often means exactly this: we follow an established set of procedures. Often the different actions and procedures are executed by different persons, departments or even companies. This leads to a process where most of the time work is blocked and waiting to be picked up again.
It is a big difference if we talk about ‘work in progress’ or ‘work in process’. And if we talk about WIP in Scrum or Kanban we are typically concerned with limiting WIP.
By limiting our work in process we are able to improve flow of work through our process an thus increase throughput and decrease cycle time.
Limiting work in progress, on the other hand, doesn’t seem to make much sense. If the work really is progressing towards our goal and improving the status quo then this is good.
At Scrum.org we are careful with the terms we use. Names are important as they influence our perception. From now on I will make it a point to use ‘work in process’ when talking about WIP and limiting it for a Scrum Team.