Quite often when you create a visualized version of your workflow you end up with a waiting column. This is where items goes while your are waiting for someone else, or something else to happen before you can continue to work on it.
It might look something like this on your board:
For example, you are writing a report and need it feedback on the report
before you can continue. Sadly that person (Daphne, let’s call her that)
that can give you feedback is sick, so you’ll have to wait until Daphne
is back again. You are blocked for this item and cannot complete it.
(Coders, exchange the word “report” for “module” and you’ll be able to
tag along 
). You move the sticky to the waiting column and pull the
next one…
This is a bad idea. Waiting-columns is a place where work items goes to die. Slowly.
I have now explained the contents of this blog post to a number of teams, although it’s simple, and thought that I should write it down so that I don’t have to restate it over and over. First if you move the sticky out of the Doing column you are losing information about it’s current status. It’s now not Doing it’s waiting. For all but the very trivial boards (as above) this is a problem when you are unblocked again. Most board have, and should have more column to more fine grained describe the stages of your workflow. To do, Analyze, Developing, Testing, Deploying and Done is another quite trivial example, but a bit better.
For the record, these trivial examples might be useful. The first one is the default for many Personal Kanban boards, and this second example is a great starting point for software development team. But we should change it as needed.
Let’s say that Daphne is sick for three weeks. Plenty of time for you to forget where that sticky actually was, let alone what it was about.
Secondly, when you move the sticky to the Waiting-column it’s just Waiting. You really don’t know why, for what or how long it’s been there. It’s like a cemetery for work items, or at least a waiting room for the care taker.
Thirdly (related to no 2), when should that item be move out of there? What if that takes much more time than you first expected? How could you know when it’s time to act and when it’s not?
I’m sure you can come up with more items if you wanted to. Here’s is my suggestion for what to do instead.
What to do instead
The habit that I’ve grown into is to not move the work item note but rather put another, waiting note on top. On this little note I can write the reason for me being blocked and also track the number of days I’ve been waiting. Like this, for example:
This means that the original work item card is intact with all it’s attributes to describe it:
- the description is beneath the waiting note and I can have a look at it if I need to remember what it was about
- my avatar is still on there so I know who will check in on the progress of this matter
- the work item is still in the same column so we know how far it has progressed
- we have created a little dot for each day we have been waiting for Daphne. Maybe we have a policy not to wait more than 5 days before trying something else. Or, we can use this number as material for an improvement discussion with a third part, or another department: “Hey, review guys, we have been tracking some data for awhile and in average we are waiting for you to review our things 6 days. That’s, also in average, 60% of our total lead time of 10 days. Can we discuss this? How can we help you?”
There’s nothing really earthshattering about this, and most teams get here after awhile, but now you can take the shortcut here and improve further.
Callbacks on your board
Oh yeah, one more thing. I once met a team that was waiting a lot. In fact, if I remember correctly, they had a waiting stage between every doing stage in their workflow. And it was maybe 80-90% of the total time. It looked like this, kind of:
I hope that no one of you end up in a state like that. There’s a time and place to stop waiting as well. If you end up waiting for each thing you do, maybe you should do them differently?
When programming JavaScript and Node programming, there’s a lot of calling back taking place. That is, you start something that takes time and as the third party performing the work to call you back when they are done. In the mean time your application are freed up to do something else, like answering the next request for example.
When the other party has finished processing his thing (saving something to a database for example), he’ll ping you back with an status about the work being done.
I think this can be used as a model for how we can design our work in situations when we end up waiting a lot. Do the first part of the work, send it to the third party to do their part (Daphne doing review in our case) and tell them to call you back when they are done. Your first item is done and you can go on to something else.
Once Daphne is done she’ll tell you that your report looked great, here’s a few spelling errors and then you can print it (or whatever). You now create a new work item, put it in the queue to be worked on, do the work when your capacity allows and then complete the report.
Objections
No wait a minute here… What if Daphne doesn’t call me back?
Well… maybe it was not important then? The wait-work-wait-team I mentioned above was waiting for 4 months in one instance, to get decision in how a bug should be treated. If you haven’t answered in 4 months – it is not important!
If it is important she will come back.
No wait a minute here… What it’s important to me and not to Daphne?
Well, don’t move it off the board then, but use the suggestions from above. One tool is seldom good for all things.