Uncharted Waters

Oct 3 2016   7:49AM GMT

What’s Wrong With Kanban

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


Last month, I wrote a post about what I think is wrong with Agile. Or at least one aspect of what I think is wrong with agile, there are plenty to choose from. That post was very popular, so I want to do a little unpacking of the Agile suitcase and look at the practices most commonly used starting with the work visualization tool, kanban.

Kanban is one of the most popular processes tied in with agile, maybe second only to Scrum. The basic idea is that every unit of work is displayed in some system as a card that moves through columns that indicate what stage the work is in right now. Add a dash of breaking work down into deliverable pieces, and a pinch of limiting work in progress, and that’s kanban. Simple, but it gets screwed up more than it is optimized for value.

Why is that?

Sock Puppet Process

The most common implementation of kanban I have seen is to take every task in a release and jam them into a kanban product like pivotal tracker or JIRA. Developers take tasks, broken down roughly if at all, and assign them to themselves. To view the entire In Progress column, I had to use scrolling, lots of scrolling to get to the bottom of the list.

One saying I hear often around agile process is that they expose problems in the development process. I think that is true because of the way teams try to use something without understanding the context and philosophy. Kanban helps teams visualize work, but there is philosophy built in that people constantly ignore. One of the hidden parts of kanban is reducing work in progress. Meaning that one person, or maybe a pair if you’re into that, takes one task at time and works on it till it is ready to go to production. That rarely happens though.

What's Wrong With Kanban

My experience is that one person takes one task, probably a part of a feature, and works on it till they are blocked by something. That something might be information from a product person, or a code dependency from another programmer. While that one task is blocked, the programmer moves on to the next piece of work in the queue. That is two pieces of work in progress now. By some stroke of luck, they are able to finish task and send it off for code review. So that task it done, but it isn’t really done. On to the next task in the list, and now that is three pieces of work in progress. This is absolutely normal in my experience. Multiply that by a few programmers on a team, and then the back and forth nature of testing and bug fixing, and you get a picture of all the work being managed like plates being spun on top of a broomstick at a circus.

The average of kanban is no work in progress limitation, and more columns added to the board that add handoffs and slow down the delivery process.

You might be saying, “that sounds like a problem with the people that implemented kanban at that company and not kanban itself.” Sure that is true, but it’s also true that hoards of people have these problems. So, is it really the people and not the ambiguous blob of process people are trying to use?

To be clear, I see a lot of value from agile and the surrounding practices. That value seems to be hit and miss and living in isolated pools in the software world. In some ways, I think talking about the value of these processes is futurism and elitism. Hopefully talking about my experiences with the practices, and little cautionary tales, will help someone have a better experience in making software.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: