No, it’s not an overdesign. But it should be taken in stages. It takes a mature Scrum team to handle the changes that Kanban brings.

In fact, I’ll go further. Scrum can work in an isolated team, though not as effectively as if the business buys into it.

Kanban requires that the business be invested in the process, as much as the team, because they need to understand what’s going on when you pull everyone’s effort off what they’re currently assigned to, so that you can clear a column out. And there’s simply no point in raising Kaizen if the business isn’t absolutely invested in reducing waste.

Google “Scrumban” and you’ll find lots of advice on mixing up the two processes, but I found one article on Lean Software Engineering particularly useful.

A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process. Time-boxing, by its nature, sets a bound on how much WIP that can be, but it can still allow much more than would be desirable.

If a kanban is a token that represents a work request, and our task board can still get out of control, then what is the problem here? The problem is that a kanban is more than just a work request on a card, and putting sticky notes on a whiteboard is not enough to implement a pull system.