Kanban: How to Work Smarter, Not Harder

Software developers seem to be constantly searching for better processes to increase efficiency and improve productivity. The old 20th-century notion of productivity tells us that eliminating downtime will increase the amount of work completed. But this thinking may be obsolete. Recently I read an article that debunked multitasking as a productive work method. It seems that trying to do too much at once prevents you from doing anything well.

Kanban is a Japanese word meaning “signal card,” and the term became a work-flow concept that was first developed by Toyota, for manufacturing cars. Toyota used signal cards to manage demand for their inventory, but the Kanban concept is now being adapted for software development processes to not only increase productivity, but to also improve product quality.

The theory behind Kanban is to pull work through the development process, rather than push work. In software development, this means that team members only work on a certain number of features or specifications at one time. When those requirements are completed, they are able to pull another feature into their part of the process. Features are only completed when they are ready to be handled by the process.

The result of managing the workload this way, as opposed to working on everything until the project is complete, is that sometimes programmers will have slack time. If you have multiple programmers working on a relatively small set of features, not everyone will be busy all of the time. This, however, is one of the positive aspects of Kanban. In their downtime, those programmers will have the opportunity to survey the current development process and identify areas for improving the quality of the software. This improves collaboration among team members and encourages them to contribute to the process as a whole.

This approach, which allows for slack time, may seem counterintuitive. However, all you are sacrificing with Kanban is the appearance of getting more work done. And that appearance of getting more done is actually detrimental to the end product, because it introduces poor quality. In his book Kanban: Successful Evolutionary Change for Your Technology Business, David Anderson describes case studies in which less skilled programmers who worked in a collaborative and Kanban-style environment produced higher quality projects and in less time than more experienced programmers who worked individually.

Anderson also proposes a Kanban “formula for success” in his book, focusing on a test-driven development environment. The idea is that the primary goal in the development process needs to be quality and that programmers should own that responsibility. Anderson believes that programmers should create the tests for the codes that they have yet to write, giving them a better sense of what needs to be done for their code to pass those tests.

There are many other components to this “formula for success,” described in “Kanban,” that I will explore in future blogs, but the central idea of pulling work through the development process can generate substantial improvements in software quality. The software development process relies on brainstorming ideas and accessing the social memory of the group. Productivity and quality deteriorate if you have so much going on that your team is unable to collaborate and help each other. The Kanban concept is proving to be a viable way to work smarter, not harder.