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.</p>
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:
- Finished work put into Step 2’s “done” queue
- Next set of available parts pulled into Step 2
- Step 2 signals Step 1 that work needs to be done
- Finished parts pulled from Step 1 into Step 1 “done” queue
- 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.
</p> </p>
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.