≡ Menu
Pawel Brodzinski on Software Project Management

Pitfalls of Kanban Series: Stalled Board

Pitfalls of Kanban Series: Stalled Board post image

One of signals that something may be wrong with a Kanban implementation is when the Kanban board’s design doesn’t change over time. Of course it is more likely that rapid changes of the board will be happening during early stages of the Kanban implementation, but even in mature teams a board that looks exactly like it did a year ago is sort of a warning light. For very fresh Kanban teams I would expect that board design would differ month-to-month.

Actually, a stalled board is more a symptom than a problem on its own. The root cause is likely the fact that the team stopped improving their process. On one hand, it is a common situation that at the beginning the potential for change is significantly higher and it diminishes over time. On the other, I’ve yet to see a perfect team that doesn’t need to improve their processes at all.

In such cases, what can one do to catalyze opportunities to discuss the board design?

One idea that comes in very handy is to watch for situations in which any team member takes an index card to update its status and, for whatever reasons, struggles to find the right place on the board to put the card. It may be so because there isn’t relevant stage in the value stream, or the work currently done isn’t in line with the rest of process, or a task is sort of specific, or what have you. This kind of situation is a great trigger to start a discussion on the board’s alignment to what the team really does and how the work is done.

Another idea is to dedicate a retrospective just to discuss the board. Such a constrained retro can be a natural opportunity to look for board-related issues or improvements in this area. I think about a class of issues that might not be painful enough to be brought as biggest problems to solve on regular basis, but, at the same time, we know that tiny changes in the board design or WIP limits can introduce tremendous changes in people’s behavior.

There is also a bigger gun – a significant board face-lift. Following the idea that Jim Benson shared during his ACE Conference keynote, teams find it easy to describe and define about 80% of processes they follow. The rest seems vague and that’s always a tricky part when you think about value stream mapping. This is, by the way, totally aligned with my experience with such exercises – I’ve yet to meet a team that can define the way they work instantly and without arguing.

Of course, introduction of visualization helps to sort this one out although it’s not that rare that we fall into a trap of idealizing our flow or just getting used to whatever is on the board.

Then you can always use the ultimate weapon and redesign your board from scratch. Probably people will have in mind the board you’ve just wiped out and will mimic it to some point. Anyway, odds are that if you start a discussion from the beginning – the moment when work items of different classes of services arrive to the team –some new insight will pop up, helping you to improve the board.

On a side note: it is also a good moment to discuss what you put on an index card exactly; I treat it as an integral part of board design, as you will need a different design for standard-sized work items and different for highly-variable projects on portfolio board.

Read the whole Kanban pitfalls series.

in: kanban

2 comments… add one

  • Paul Klipp August 2, 2012, 1:44 am

    I think this is very true in the early days of a project, but more mature teams will probably see less dynamic board designs. However, I agree that even the most mature teams should re-visit their workflow from time to time and be alert to the risk of “following the board” rather than the other way around.

  • Vin D'Amico August 2, 2012, 9:13 am

    I agree. The Kanban board should be a reflection of the software development process. As the process matures and evolves, the board should do the same. Regrettably, many teams try to create a ‘perfect’ Kanban board and align their development process with it. That’s backwards.

    The objective isn’t to create a great Kanban board. It’s to define a great process or workflow. The purpose of the board is to help identify bottlenecks and inefficiencies so that we can improve the process. Is this concept really so hard to grasp?

    Anyway, great post! Thanks for sharing.

Leave a Comment