A Kanban Is Just A Signal To Do Work

A kanban is a signal to do something. I don’t think kanban implies a pull-based system, honestly. Joe Ocampo showed it best in his Scrumban presentation at Austin Code Camp:


That’s not a signal to pull anything… it’s a signal to RUN FOR YOUR LIFE!!! :) Now, having said that – I do think that a pull-based system is facilitated by kanban.

A Simple Kanban Enabled, Pull-Based Workflow

In a pull-based system, a kanban is used to signal the upstream process of the downstream needs. As an example, let’s look at a simple 2-step process.

Step 1 produces 10 parts and moves them into the “DONE” queue, saying that they are ready to be used by the next step.


Step 2 then uses 5 of those parts by pulling them out of Step 1’s “DONE” queue.


When Step 2 pulls those 5 parts out, the person doing Step 2 will signal Step 1 to make more parts. That is, they send a kanban back to Step 1, telling Step 1 that more parts need to be produced. This kanban may be a card, an email, a tap-on-the-shoulder, or any other mechanism that anyone can think of, to tell the previous step that work needs to be done.


When Step 2 is done, the parts can be put into the next queue. Step 2 then pulls the next set of parts out of Step 1’s “DONE” queue, and the cycle starts over…


To properly understand the flow of work in this diagram, read from right to left:

  1. Finished work put into Step 2’s “done” queue
  2. Next set of available parts pulled into Step 2
  3. Step 2 signals Step 1 that work needs to be done
  4. Finished parts pulled from Step 1 into Step 1 “done” queue
  5. Repeat from #1

A Task Card Is Not A Kanban

I was involved in a project that ended a few months ago, where we did some experimenting with a pull-based, kanban-enabled workflow. The following picture is what our process looked like and was a direct outcome of the research and learning that went into my previous Kanban In Software Development posts.


(Note: Please disregard the glaring problems with this board. It was a learning experience for me and my team. :) )

Our kanban – our signal for an upstream process to provide more input for the downstream process – was not the task cards that moved across the board. In fact, I think calling a task card (a user story, an MMF, a function point, or whatever it is) a kanban is a serious misrepresentation of kanban. The task cards are exactly that – task cards. They are the work to be done, the work in process, and the inventory in queues.

My Team’s Kanban: Nothing

For my team, the signal to do more work was an empty stikki clip.


That empty slot in the “System Test” column was a signal to the testers that they could pull another task from the upstream process. The empty slot in “In Dev” was a signal to pull from their upstream. And the empty slot in “Analysis & Estimation” … you get the idea, right?

Kanban vs kanban

A kanban is just a signal for work to be done. It doesn’t have to be a “kanban card”. It doesn’t have to be any thing, actually – it may be the absence of something, as was the case in that project. In the end, I think the idea of calling that project’s board a “kanban board” was a misrepresentation of kanban. Additionally, there’s some interesting   banter   going around   the blogs on kanban as a tool, more than just a tool, kanban vs “Kaban” (capital K), and how the software industry has branded a pull-based, signal-enabled workflow system as capital-K “Kanban” (and I can’t help but think that I contributed to this situation). So, maybe I can call this a “Kanban” board… but just because I can, doesn’t mean I should.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Kanban, Lean Systems, Workflow. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Great post. It seems to be an up hill battle though. If we don’t call the board Kanban, then what’s the name? “Task Board?”

    It seems most of the confusion is caused by the branding process. Not sure how we swim up stream at this point.

  • Great article! Love the sticky clips concept. Awesome. Can you drop me a line dja at agilemanagement dot net. I’d like to discuss this further.

    PS Blogged a link to this

  • The stikki clips have a nice advantage over pushpins in a corkboard: They clearly enforce your queue limits. You can’t put another thing into “ready for test” if there isn’t an available clip. I like it.

    Kanban has caught my interest lately because I think my team’s flow could be improved by a concept of queue limits. Those clips are a nice tangible reminder of the concept.

    By the way, may I ask why there are ducks?

  • @Troy,

    Thanks! … i’m honestly waffling on whether or not call it a task board or a kanban board, or …. ??? a WIP Limit board ??? or ??? i don’t really know. I’m leaning toward not liking kanban board, but I’m not going to rule that out yet, since that seems to be the common name at this point.


    Thanks! and i sent you an email…


    ya, the clips worked a lot of magic for us, without any realization until recently. I started using the clips after Dave Laribee suggested it at KaizenConf last year, and while I was building this board I realized that I could build in the WIP limits by limiting the number of clips per task column. The revelation of an empty clip becoming our kanban didn’t occur until recently. it was never formalized, or discussed in our team… it was just how we worked.

    as for the ducks… i was waiting for someone to ask. :)

    our codename for the project was “DuckLeg” (it’s short, boring story). one of the team members has his kid cut out about 50 duck shaped task cards one weekend, and brought them in the next monday. we all thought it was pretty funny, so we used them.

  • jdn

    I guess I’m not sure why it is really a concern to call it a kanban board. I think anyone learning the very basics of kanban can easily grasp that a kanban board is a task listing thingy with queues that have numerical limits and cards/post-its/whatever that are the numerals.

    It’s obviously only the beginning of learning Kanban/Pull/Lean/Whatever, but it is so easy to grasp and it gets at the heart of the matter, I think.

  • You are right that a kanban does not necessarily imply a pull system. A kanban is just a token. However, a kanban system, which is a technical term for a process control system created by Taichi Ohno, is _always_ a pull system.

    It is also helpful to know that in a kanban system, there are two types of kanban:

    Work-In-Process kanban, i.e. the Post-It notes on your board.
    Withdrawal kanban, i.e. the stikki clips on your board

    Here is an article about defining kanban: http://kallokain.blogspot.com/2009/06/defining-kanban.html

    The article was picked up by DZone recently.