KANBAN is borrowed from Lean manufacturing practices. Its focus is on improving the productivity of individual resources by ensuring there is always a pick list of work to “pull” down and work on. It sounds good in theory. And, it may even work on improving individual productivity on development teams. However, building software is not the same as building cars or taking chocolate off a conveyor belt:
As I mentioned in my last blog post on “Why do technology projects fail?” building software isn’t as simple as just executing a bunch of simple tasks.
Because users expect a well-designed solution, and because these expectations are rising, processes that focus primarily on the efficiency of the team or its individuals instead of on the quality and design of the product are likely to steer most organizations in the wrong direction. And in fact, this is what we are seeing.
In the last 6 months, we’ve seen 3 projects based on KANBAN fail. In each case, the team felt good about their progress. They liked the method. They liked the tools that supported it. And they all failed. They failed to deliver on a reasonable schedule and they failed to deliver software that people wanted to use. But, I’m sure they did it efficiently.
Technology guys: KANBAN at your own risk.
