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):
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 2x2 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”.