In Progress v In Process

After a recent webinar with SwiftKanban, I received an email from a manager in Sweden with several teams that had workflows difficult to tame.

He said:

I help teams getting started with Kanban and have some teams that are very similar to the architect example you showed in the webinar. These teams typically struggle with having many tasks and tasks that take a long time. Hence as you mentioned in the talk a “normal” WIP limit is not all that useful. We have tried various approaches such as priority columns or date columns combined with people rows. To some extent it works, but we still struggle to get enough information on the board for it to be really operational.

After some e-mails were exchanged, it became clear to me that we tend to treat the phrases “work-in-process” and “work-in-progress” as interchangeable. But, especially for teams with a great deal of churn, like QC or other external influences to their cycle. This WIP distinction is key to a flowing kanban.

Work-in-process is all work that is on our kanban and is actively flowing through our process.

Work-in-progress is work that we are actively working on right this minute.

These two competing types of WIP have been overlooked or under appreciated because the concept of WIP came from manufacturing – a much more controlled environment than knowledge work. Manufacturing has less churn and less complexity than knowledge work.

So, we can deal with theory later, let’s talk practicalities.

Recursive Work and WIP

If you have a request / revise / revise / revise / revise / release cycle, what is actually your personal WIP?

Let’s say that your value stream looks like this:


Receive Work Request -> Work -> Review -> Work -> Review -> Work ->
Final Review -> Final Work -> Release

WIP can get pretty confusing, especially if work items dwell in a review state for an extended period. This, in turn, can be exacerbated by demanding clients who take a long time to review, then demand updated product from you immediately after they finally return their review. (Sound familiar?)

So, your kanban would look something like this (click to enlarge):

Knowledge Work Recursive Kanban

The issue here is that a team that is waiting on external tasks, but has a predictable work cycle, can easily lose track of the difference between being responsible for a task and actively working on that task.

It’s easy to conceptualize that we throw the work over the wall into review and then they throw it back – but life doesn’t work like that. We’re still responsible for completion for all the work that we have in process, even if it isn’t – for us personally – in progress.

So, we can be happy that we’re maintaining our personal WIP limits by not having too many tasks active. We are focusing, completing, and keeping quality high.

But! .. But!

The Review columns still have their own limits. If they are exceeded – that becomes your personal WIP. You are responsible for keeping those lanes flowing.

An unspoken part of your WIP is maintaining what those columns represent, and that’s relationships. Each column is a point of negotiation between your team and whoever is doing the reviewing. Each of those transitions for knowledge work is some things that Lean doesn’t like to admit exists – politics and personalities.

These are intrinsic elements in knowledge work because, whether we like to admit it or not, much of the acceptance criteria of knowledge work is subjective. (Any guess why objective metrics and knowledge work at best have inconsistent results?)

This is a board we describe in our whitepaper Kanban: Diversity and Optimization in Knowledge Working Teams. This board is for a team of systems architects that have several active projects that require some level of consistent monitoring (or at least acknowledgement). However, they also have tasks that are currently requiring a great deal of their attention.

Their active WIP is displayed in the 2×2 matrix on the right in this photo. Their work is on two axes. The vertical axis is time until the project is complete with 4 months at the top and imminent at the bottom. The horizontal axis is the amount of time they are currently spending on the task ranging from a low of almost none to a high of almost all.

As one might guess, this is a subjective view of a domain with extremely high variation. In this case the architects are recognizing the variation in their work and attempting to visualize and manage it.

An Imprecise Closing

Thinking about what WIP means is extremely important if we are going to be honest about the complexities inherent in knowledge work. A dogmatic view of WIP will render Lean and kanban unusable for many teams.

However, the more we open the door for interpretation for what WIP means, the more we are opening the door for people to become lax in limiting WIP in the first place.  In the cases listed here, both work flows will benefit from limiting both types of WIP.

When limiting work-in-progress, we can enact local optimizations that are easy for us to implement and control. When limiting overall work-in-process for a complicated organization, we will have to engage not only mechanistic process measures, but also political ones. Perhaps this is what’s most important. It’s easy to do the former, harder to do the latter – so we optimize ourselves and wish the rest of the organization or our customers would just “get better”.

modusIn Progress v In Process

3 Comments on “In Progress v In Process”

  1. Dennis Stevens


    Nice post. You do great work building this content. With responses to comments now pending is this work-in-process, work-in-progress (since you certainly anticipated some comments), or new work entering the system?

  2. Sune

    Great post based on our interaction.

    I certainly htink that distiguishing between work-in-process and work-in-progress is a key consideration when working in environments with external suppliers or where you support other projects or business areas.

    Hence we need to exposed (visualise) this in our board, which is the first challenge. How to do this in a given situation. Your picture with the “work-review-work-…” is a good example where is resembles the process. Thus this is likely an “easy” case. A more difficult one is when two processes are running synchronously, e.g. both us and supplier have to analyse, develop, test, prepare for prod, … and it may not be so obvious that one step comes before another. This kind of situation I have not a answer for right know, but we are looking at several approaches, for example; splitting in small work items (tasks), making 2D matrices instead of swimlanes, elaborate quality gates on the process (make it more rigid).

    Another issue with this kind of work is the follow-up. I have a work item that is work-in-process, but really not work-in-progress. However, it does need attention from time to time to ensure progress in the external process. I guess the 2×2 matrice in the architect team is one way to handle this. Currently, I am also thinking about some kind of visual markers to ensure follow-up at specific time. For example, just a date on the work item or maybe just a timeline from leave alone to needs attention and then you can move it along the line. I have not yet tried any of these, since it is the teams decision what to do.

    Thanks for the post!


    PS – I am placed in Copenhagen and actually not a manager, but an agile coach (I probably phrased my initial question like I was the manager of the team – sorry for that)

Leave a Reply

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