Why you're (probably) doing Kanban wrong

Kanban has been an accepted way of organising software maintenance for a long time, but we're now seeing a lot of companies embrace it as the new hotness for running feature development as well. There's a lot to like; you can effectively prevent your team from working on ten different things while making progress on none of them, while also being able to track tasks which are traditionally "out of band" in Scrum such as preparing stories to an acceptable state for development.

Unfortunately, we're also seeing the same type of problems as we did when "Agile" mutated from a well-defined set of principles to a trendy buzzword for flying by the seat of your pants. Namely, a lot of companies claiming to do it, but very few actually doing so successfully according to the principles. Sound familiar? Luckily, just as most of Kanban is lightweight, the test to verify whether you're doing it right is similarly lightweight:

Does your Kanban board have strict limits on how many tasks can be in each state, and do you adhere to them?

If you're not doing this, then just like those companies which weren't Agile, you're not Kanban. The whole point of the process is to prevent bottlenecks caused by a large number of tasks building up in any one place. You've got a ton of things sitting in the QA queue? Ease up on the new development and get some testing happening. There's a gigantic stack of items ready for dev? Stop adding features and start helping your development team get what's there done. Huge pile of tickets in the Done column? Release that code and get them off the board.

Kanban works when you maintain consistent flow across all activities. Think of it like a river; you don't want to overwhelm it at any point, but you don't want it to run dry anywhere either. Limits are the mechanism by which this happens. If you can only have three tasks in development and all of them are blocked, it's up to the team to go and resolve one of those blockers, rather than keep pulling new tasks until they exhaust the list of stories ready for development while not actually getting anything done. Your board is a constant reminder of this - the thing that tells you, "I can't push any more work here, those people are swamped and I need to help out" or, "we're running a bit dry, let's take on some more work".

If you don't do this, you don't get that steady stream of development; you get something closer to Waterfall. BAs concentrate on throwing as many things over the line as they can, developers focus on getting that pile of tasks over into QA, then ops are sitting around twiddling their thumbs because everything's backed up in the previous queues and there's nothing to deploy. (And I mention these functions separately, because this sort of pretend Kanban actively prevents cross-functional teams, by never giving anyone an incentive to help with anything outside whichever queue they're focused on.) At this point you may as well just write all your specifications up front, do all your development in a big block, then throw it over the wall for testing, because that's what people are trying to do when there are no limits to keep them agile.

Kanban is great - but like all of this, it's a process, and you need to learn how to do it right, otherwise it's not worth doing.