≡ Menu
Pawel Brodzinski on Software Project Management

Pitfalls of Kanban Series: Kanban Board Not Up To Date

Pitfalls of Kanban Series: Kanban Board Not Up To Date post image

This is something I see very often and at least in a couple of flavors. The problem can be a team member who haven’t really bought the whole thing and see little value in updating all these stickies on the board every time something changes. It can be more a whole team’s thing – Kanban implementation has its leader, or a champion, and when they have a day off suddenly the board starts to deteriorate as people don’t feel pushed or obligated to update anything.

On a side note: I would put it on the same shelf in my mind as when Scrum teams don’t do daily stand-ups when a leader is out.

This issue is tricky as it doesn’t seem to be much harmful but, if tolerated, it basically renders the whole Kanban implementation useless. The first step we do with Kanban is we visualize all the work. Basing on that we make informed project decisions every single day (with help of WIP limits, explicit policies etc.)

Now, if the board isn’t up to date these decisions are made on a basis which doesn’t reflect the reality. We may violate the limits or cease to help a colleague with a critical issue not even knowing about that. This way, not only do we make suboptimal everyday decisions but we also cripple the biggest power of Kanban – its improvement mechanism.

Potential solutions of this problem depend on what flavor of the problem you face. If it is a single person you can work with them to convince them there is value in updated board for them too. You can also ask them to give everyone in the team a credit of trust and give a method a try for a few weeks or a couple of months. It usually is enough to turn them back into the light side of the force.

However, in the worst case scenario you last resort may be setting up a proxy who updates the board instead of a problematic person. It will be a hit on team’s morale (“we have someone who is treated differently”) but it’s a tradeoff some teams are willing to make. Especially that, eventually such person either changes their behavior or leaves a team.

If we think of a whole group not updating the board it is a signal that there’s little or no buy-in for the idea. Unless this can be changed most likely the Kanban implementation is doomed.

The way of getting team’s buy-in will of course depend on people. However, I find it pretty successful to ask the group to give the method a try. Of course considering there is a problem I believe Kanban can help to fix quickly. Thanks to simplicity of Kanban it doesn’t cost much hassle to “try it” and pretty often first results are rather quick as almost always teams have some low-hanging fruits in terms of improvements they can make – quick wins they just aren’t aware of.

Read the whole Pitfalls of Kanban series.

in: kanban

5 comments… add one

  • Tobias Mayer April 26, 2012, 1:16 pm

    Interesting post. The same is true for Scrum boards too, of course. Lack of total team buy in for the tool will ensure it is not only useless, but actually worse than useless as it radiates false information (as you point out).

    I don’t know if Kanban teams (if such an entity exists?) meet daily to align with one another. A board is only an aid—a way to visualize, but it isn’t collaboration without the necessary people interacting with it. The daily team meeting is one excellent way of having the entire team own the board, and ensure it reflects reality. No one person, or proxy will ever achive that in a meaningful way.

  • Pawel Brodzinski April 26, 2012, 2:06 pm

    @Tobias – I guess it wouldn’t be a big overgeneralization to assume this problem is common for pretty much any task board, no matter the specific name.

    Whenever I’m using a term “Kanban team” I refer to “a team that is using Kanban” as there’s no definition of how such team should, or could, look like. And vast majority Kanban teams I know are meeting daily and I treat it as one of best practices which is almost a sure shot. A daily meeting is a great way to get the board updated and get synchronized with each other. If during the day many things are changing it may be insufficient, thus for me it isn’t the ideal solution.

    However you point one thing I haven’t thought of – active usage of the board during meetings may help you deal with lack of collective ownership of the board among the team, thus address the root cause of the problem.

  • Vin D'Amico April 27, 2012, 10:50 am

    This issue can be applied to any process or procedure where people are expected to perform an action during the project. There will always be someone on the team who is lazy, forgetful or simply rude.

    Peer pressure can be a powerful motivator. Everyone needs to nudge the offender toward compliance. If it’s only the team leader (or Scrum Master) who does the nudging, resentment will build and the team will suffer.

  • Pawel Brodzinski May 6, 2012, 9:58 am

    @Vin – Of course, you’re right. The issue is more general. However Kanban is especially vulnerable against such attitude as it offers you no specific process so with almost any project-related decision you base on the content of the board.

  • Paul November 13, 2018, 4:34 pm

    I guess I’m another one of those guys, sorry. To me, the “whole Kanban implementation” is already useless. It’s touted for “visualization”, but I can visualize just as easily by looking at rows in a query – makes no difference to me whether it’s a row or a box, except that a row takes up less space. The other benefit is to “reduce lead time”, but why would I care about that? I care about how much work my team can complete in a unit of time, not about how long it’s been since the work was requested. If some work is needed faster than other work, I raise its priority. Reducing average lead time isn’t going to help us do more; in fact it makes us do less, because we’re spending time on processes to minimize a metric that doesn’t matter instead of one that does. The only thing Kanban is moderately useful for is to identify bottlenecks.

Leave a Comment