I first heard about “kanban” years ago, when a former boss and agile coach, started talking about it more and more. At the time, I let it slide as a fad, but it was in the back of my mind as I went through life. It wasn’t until last year, when I started looking for a replacement to my failing to do lists, reminder programs, and GTD systems, that I returned to the idea.

At the time, I was looking for that replacement, and remembering how well I did with an agile environment. I remebered how effective the task board always was for me, and started planning a personal agile system in my head. Then I remembered this “kanban” idea, and started looking into it. What I found intrigued me, I read everything I could find, and eventually came to Personal Kanban.

A kanban, is a method of increasing transparency usually found in manufacturing environments. In short:

The first official use of kanban can be traced to Taiichi Ohno’s work at Toyota. He needed a way to quickly communicate to all workers how much work was being done, in what state it was, and how the work was being done. His goal was to make work processes transparent – meaning he wanted everyone, not just managers to know what was “really” going on.  The goal was to empower line workers to improve how Toyota worked. Everyone had a hand in making Toyota better.

(from www.personalkanban.com/pk/primers/what-is-a-kanban/)

Personal Kanban, is similar, but is more focused on knowledge workers’ tasks. Overall, it really boils down to 2 rules:

1. Limit your work in progress
2. Visualize your work

That’s it! This was perfect for me. A system that gave me structure, that still allowed me to be flexible in how I applied it.

My use of personal kanban has been pretty steady since then, and my flow has evolved. I started with the common:

Ready > Doing > Done

Currently, it is a little more complex:

Backlog > Investigate(3) > Ready > Doing (3) > Done

This means that items start in my backlog. I then pull up to 3 items into my investigate column, where I ensure I know what the task really means. This is where I break the task up, get better estimates, and identify any potential questions or blockers that I need clarification on. Once I investigate, I move it to a ready state, and then, when I’m ready, I pull it into the Doing state, which is where I actually do the item. I don’t move another item into the Doing state until I move an item out of it (see rule number 1).

I track all of this on a kanban board, which is like a scrum board (above), but with more columns. I use color to associate items with projects, and at times, i’ll include information about estimates, or bug numbers on the post-it notes.

This works for me, but it still evolves; I change the board when I have new needs, or when the board isn’t properly giving me the feedback about what is going on. My goal with it is to make it get out of the way as much as possible, and eventually, to move it to a Moleskine notebook, like

(from here)

That will give me a level of mobility for my board, without requiring me to have network connections, or carry around a whiteboard to get erased.

I’ve found kanban to be a useful tool for me, and I’m always learning more about it, and how to use it better. I love to hear other perspectives though, so if you have one, feel free to chime in!