Early 1940s. The first Kanban system was developed by Taiichi Ohno for Toyota in Japan. He thought of a simple planning system to control and manage work and inventory at every stage of production optimally. It revolved around a board with columns and cards.
The Kanban board is everything. In fact, there is no such a thing as a Scrum board. All boards we see around the world with columns and statuses and work represented as little cards moving through columns are Kanban boards. This tool was created from the Kanban principle that we should visualize everything, as in ALL the work. All stages. All blockers. Everything. Thanks Taiichi!
The case for visualization: we are humans
Give it some though. You know when you are overwhelmed by some explanations and concepts that words are not enough and you ask “can you draw it for me?”. Or when you attempt to organize drawers and bookshelves and you really need to remove everything, classify, maybe throw some stuff out? Or the reason why you use a scheduler or an agenda? Visualization is powerful. In fact, humans process most of life through their eyes. The area of the brain that takes care of visual processing in the cortex takes up 50% our brain. So, visualizing the right stuff is very telling.
Make friends with the board
In the particular case of the Kanban board, everything is information. The little cards contain all needed information so we know what the work is: a description, date started, who’s working on it. Maybe a red dot to show it is blocked. You really don’t need much and yet the little card already told you a lot in itself.
Now, we also need to know where we are at, in what stage of the process. That’s why we design the process as it is by using columns. TODO | DOING | DONE is great for some teams, definitely good for starting out, but the intention is that we understand our processes so we know exactly how the work is progressing. Where is it stuck? Is it stuck in risk analysis? Is it stuck in deployment? Did it barely depart in our process? The board is a fantastic tool, so make your process fully visible and only later simplify it. Simplify it when it actually becomes simpler, not by omitting or aggregating steps. That hides key information.
We also need to know the why, so that we can make things move. That’s the reason we “walk the board”. We gather in front of it to tell each other the story on how it is all progressing. We saw when the work started, where it is at, who’s working on it and now we want to make sure it keeps flowing. We don’t just accept blockers in Kanban. Blockage has to be removed. Blockers impact lead time, which is time to customer happiness. Do you want a frown or a smile in the customer’s face? Let’s unblock that work item!
Keep the board tidy
The above has many implications that people cannot run away from.
The first is keeping the board tidy. The board is both information for us and stakeholders and also our control panel. Daily, or even at every shift turn in factories, we walk the board. The Daily Standup is an appreciation of the status of the board (aka, work representation) and of what everybody is doing and how well it is going.
The second is the board as the source of truth and self-management: you cannot work on stuff that is not on the board. You cannot hide work. If it is not on the board it is not to be worked on. And if it is on the board, what are you doing to make sure that it moves sequentially through the board, to the completion stage?
A third, but no less important reason: nobody better than the workers themselves to talk about the work done or blocked. The team, if nobody else, has to walk the board. You know when people get upset or annoyed to go to the board or to update that Jira ticket? Well, in Kanban, the board is the single source of truth for work. So having an out-of-date board is unacceptable. Not knowing what your peers are working on is unacceptable. There is no excuse for not updating the status of things be it a physical board or a tool like Jira. The system is designed to use the board. It is probably the paramount practice in Kanban.
There’s no Kanban without the board
Such a simple tool can unlock so much knowledge and yet cause so much commotion on how teams work together and communicate their work. Whenever people seem to find the board too ludic to be taken seriously or jut unimportant and “nice-to-have” I find helpful to remind my teams the board will host most of the important team policies and ways of working:
- The maximum amount of work allowed for a team to work on at at time (the famous WIP limit) to maintain flow is expressed in the board.
- The actual stages the work goes through is designed as columns on the board.
- People’s names, the team, is on the board.
- The description of the work being done is on the board.
In just one look you can see how much work is done, work that is accumulating somewhere else plus all of the above. This is transparency. Transparency is a tenet of Kanban.
Anyone can benefit from the board and many Agile frameworks and even personal approaches use it. There is board without Kanban, but there is no Kanban without the board.
