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 later).
Yet this is largely unknown outside of software development. All sorts of industries would benefit from this approach, from farming to law.
Terminology
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 planning:
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
Tips
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 plan work.
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 information.
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 plans.
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!