Steve Fenton

Making work visible, board management, and software

Kanban boards are now becoming so popular that they are subject to the mainstream effect. This means that it is worth thinking about some of the common problems.

First and foremost, both Lean Software Development and Kanban advocate starting from where you are. So the first role of a Kanban board is to help you understand where you are now by visualising the work in process, and by helping you to make the real process visible (not the process you think you have, or wish you had). Only when you can see the current situation can you start the work of improving it; a task that should never end.

To discover where you are, start by creating a card for every piece of work, and a column for each hand-off. You can add or remove detail as you go, with the initial goal of learning what your starting point is. There is a big temptation to create a board based on an ideal way of working, but this must be resisted as the board must be a clear reflection of reality and should change only to keep up with reality. Reality moves first. Then the board follows.

Now lets turn our attention to some common problems.

Fear of forgetting

People are plagued by the fear that they might forget an idea. Some people sleep with a notepad and pen close to hand, worried that they will invent an amazing idea during the night and forget it before morning. These notepads are full of mediocre thoughts that seem brilliant when the lights are out. Similarly, boards will attract mediocre work. If an idea is not good enough to be worked on this month, it isn’t good enough to be given space on the board. If an idea has merit, it will never be forgotten as something will trigger its remembrance or re-invention when the time is right. Software boards make it seem cheap to store a million ideas in the “Todo” column, but they are just as lost there as they are if they are never written down. The cost of managing a large backlog of “potential ideas” is immense and will cause you to lose the great ideas in the murky mediocrity of a jammed list.

Boards organised by “type”

This is more common when software is used to manage boards, but creating a board for each “type of thing” can seem like a nice way to tidy up the work. This is problematic for several reasons. First and foremost, by dividing work amongst many boards you are hiding the true scale of the problem, because you cannot see all of the work. This technique can be made worse by expecting people to work on multiple boards, because now it is practically impossible to use work in process limits effectively. It is also difficult to ensure that the most important work is being done first, because anyone looking at multiple boards has as many “most important” items as there are boards.

No WIP limits

Failing to apply WIP limits is one of the most common problems on Kanban boards. You could write a book on the benefits of limiting work in process (and Jim Benson has), yet teams and organisations still have a mindset of wanting everything, yesterday. The failure to apply WIP limits is a symptom of utilisation-thinking rather than flow-thinking. If you can’t stand the thought of a person being idle, you are a utilisation-thinker. You will need to study hard to find out whey keeping the work moving is more important than keeping people busy.

On the whole, unless you have an expert-level of knowledge of Theory of Constraints and Kanban, you’d be better off avoiding software boards as they encourage a myriad bad behaviours. Once you have the expert-knowledge, you are likely to avoid software boards for a whole different reason.

Written by Steve Fenton on