I continue to be staggered at the effectiveness, as a process management
technique, of simply sticking cards representing tasks onto a whiteboard.
Whatever your industry or project management methodology, the ability it offers
to visualise the flow of work is immensely powerful. It lets us plan the
current work and the near future to maximise our productivity.
It's valuable whether you're working on your own or working as a team. When
working as a team, it can be used to schedule work among team members. When on
your own, it merely helps with clarity of thought (we'll look at why a little
Yet this is largely unknown outside of software development. All sorts of
industries would benefit from this approach, from farming to law.
There's lots of variation in the terminology around kanbans, so let me lay out
the terms as I use them.
The idea of a kanban originates in manufacturing in Japan. The word itself
means sign board and refers to the board itself. Specific processes built
around a kanban are called kanban methodologies. Scrum calls the kanban a
"Scrum Board" and naturally there are all manner of other terms and practices
for using a similar approach in other methodologies too.
Onto the kanban we need to stick cards representing tasks - small pieces of
work that are easy to pick up and get done. Sometimes tasks will relate to
bigger projects. Some call these bigger projects epics, and may use
additional cards to represent the relationship of tasks to epics.
A backlog is the totality of the work yet to do (and again, terms differ;
some practices may exclude work that is already scheduled).
How to run a kanban
First of all, get yourself a real, physical whiteboard. If you can get a
magnetic whiteboard, you can stick task cards to it with magnets, which is nice
and clean. But otherwise your tasks can be cards stuck to the board with
blu-tak, or post-it notes. I favour index cards of a weighty paper density,
about the size of your hand when flat. This lets you write large, clear letters
on them, which are easier to see from a distance, and they are somewhat
resistant to being scuffed as you stack them into a deck and riffle through it.
Next, you need to come up with your backlog. If you're in the middle of a piece
of work, you can start by braindumping the current state. Otherwise, get into a
quiet room, with the appropriate people if necessary, and a stack of index
cards, and write out cards, or break them down, or tear them up, until you have
a set of concrete tasks that will get you to your goal. Make sure everyone
agrees the cards are correct.
The cards can include all kinds of extra information that will help you plan
the work. For example, you might include deadlines or an estimate (in hours,
days or your own unit - I like "ideal hours").
Sometimes tasks are easy to describe on a card but if you were to pick up the
card as something to work on, it wouldn't be immediately obvious where to
start. These should be broken down into smaller pieces of work during this
planning phase. This allows you to see with better granularity how much of the
large piece of work is done. I like tasks that are of an appropriate size for
each person to do several of them in a week. However, it's OK to break down
the card into smaller tasks later if the task is probably going to be something
to tackle further in the future.
Now, divide the whiteboard into columns. You will need at least two: something
like backlog, and in progress. But you could have many more. Kanban is
about flow. Tasks flow through the columns. The flow represents the phases of
working on a task. You might start by quoting for work and finish by billing
for it. Or you might start by making sure you have all the raw materials
required and finish by taking inventory of materials used.
None of these practices are set in stone - you can select them and reselect
them as your practices evolve. For example, you could focus on longer-range
So with your whiteboard drawn, you can put your tasks on the board. Naturally
many of your cards may not fit, so you can keep your backlog stack somewhere
else. Choosing what to put on the board becomes important.
Now, just move the cards to reflect the current state. When a task is done, you
update the board and choose the next most valuable task to move forward. You
might put initials by a card to indicate who is working on it.
Visit the kanban regularly, as a team. Stop and replan frequently - anything
from a couple of times a week up to a couple of times a day - especially when
new information becomes available. This might involve pulling cards from the
backlog onto the board, writing new cards, tearing up cards that have become
redundant, and rearranging the board to reprioritise. Make sure the right
people are present every time if possible.
Less frequently you might make a bigger planning effort: pick up all the cards
from your backlog pile or column, and sit down again with the relevant people
to replan these and reassess all their priorities. Some of the cards may be
redundant and some new work may have been identified.
The value of the kanban will then naturally begin to flow:
- Higher productivity as you see how what you're working on fits into a whole
- A greater ability to reschedule - for example, to park work in progress to
tackle something urgent
- Team collaboration around tasks that seem to be problematic
- Estimates of when something might get done or which deadines are at risk
A physical whiteboard seems to be very important. A lot of the practices don't
seem to evolve properly if you use some sort of digital version of a kanban.
There are lots of reasons for this. One obvious one is that physical
whiteboards offer the ability to annotate the kanban with little hints,
initials, or whatever. Another one is that an online whiteboard doesn't beg to
be looked at; a physical whiteboard up in your workplace is something to notice
frequently, as well as offer a designated place to get away from a screen and
Naturally, having a physical whiteboard is only possible if your team is not
geographically distributed. Geographically distributed teams are challenging
for a whole host of reasons, and this is just one. A digital version of a
kanban may be a good approach in those cases. Or perhaps frequent photos of a
physical whiteboard elsewhere in the world can help to keep things in sync.
Readability from a distance helps get value from your kanban. Write in capital
letters because these are more readable from a distance. Use a broad felt pen.
Use differently coloured index cards or magnets to convey additional
It's somewhat important to ensure that the kanban captures all streams of work.
There's a tendency to think "This isn't part of the project we're planning;
let's not get distracted by it". But that reduces the value of the kanban in
tracking what is actually happening in your workflow. Obviously, different
streams of work can be put in a different place on the kanban, or use
differently coloured cards.
You can also track obstacles to delivering work on the board. I like to reserve
red cards to indicate obstacles. Removing those obstacles may require work!
Why Kanbans work
Kanbans are certainly a form of process visualisation. Enabling you to
visualise how tasks are flowing will let you spot problems in the process, such
as too much work building up that only a certain team member can do. You can
design workarounds to a problem like this also right there on the kanban.
Stepping back from this, the reason I've found having a kanban useful even for
solo work may be related to the psychological idea of transactive memory,
where we use our memory not as a primary store of information, but as an index
over other stores of information, such as those in other people's heads, or on
paper. The model of thought is then very much like a database transaction - we
might "read" a number of facts from different sources into working memory,
generate some new insight, and "write" that insight back to an external source.
By committing our understanding of our backlog of work to index cards, we can
free our memories to focus on the task at hand. And when that task is done, we
waste no time in switching back to a view of our workflow that can tell us
immediately "what's next". Or say we encounter new information that we suspect
affects something in the backlog - being able to go straight back to that card
and recover exactly how we defined the task turns out to be useful: it allows
us to quickly assess the impact of new information to our existing ideas and
The final reason I believe kanbans work so well is that both the kanban and the
stack of cards that represent your backlog are artifacts that are constructed
collaboratively in a group. Taking some concrete artifact out of a meeting as a
record of what was said cuts down a lot on misremembered conclusions
afterwards. Some people try to take "action points" out of meetings for the
same reason, and then quote them back to everyone by e-mail afterwards. This
doesn't seem to work as well - I often find myself thinking "I don't recall
agreeing that!" One reason for this is that the record of the action points is
not written down for all to see and approve/veto, but a personal list written
by the person taking the minutes.
Writing tasks out on index cards in front of people, and reading them out
repeatedly or handing them around (or laying them out on the table for people
to move around and reorganise - related in principle to CRC Cards), means
that everyone gets a chance to internalise or reject the wording on the card.
Similarly, the organisation of kanban is not only a concrete artifact that is
modified with other people standing around: it is ever-present to consult and
correct. Nobody can have an excuse to leave the kanban in an incorrect state.
Thus the kanban is a reliable source of truth.
So whatever your industry, whatever your process methodology, set yourself up
a kanban and give it a try. Happy kanbanning!