I’ve never made it a secret that I am a fan of agile management practices, both inside and outside of software development. Historically, however, two things within the agile space have always been a little bit frustrating to me:
I have heard about Kanban systems applied to software development for a while now, but mostly through conversations with other agile practitioners. After doing some research, I’ve found that there were not many resources on the internet about Kanban and how it is used in agile development. So I decided to pull something together here and use it as a basis for further discussion.
First, what exactly is Kanban?
The word kanban is Japanese. Roughly translated, it means ‘signboard’, ‘billboard’ or ‘card you can see.’ In its original usage in 17th century Japan, Kanban was a wooden or metal sign often used to represent a trademark or seal.
In more modern times, however, Kanban became a term used in Just-in-time (JIT) manufacturing systems that seek to reduce in-process inventory and its associated carrying costs, most notably by Toyota. Thus the concept of Just-in-time manufacturing has also become known as the Toyota Production System (TPS).
JIT or TPS is a lean, pull system of production. American manufacturing has traditionally been based on a push system where the manufacturer estimates the quantity of product it must produce in order to meet forecast demand. A push system can result in either a shortage or surplus of materials needed for production depending on the accuracy of that forecast.
Conversely, pull systems like those used in the TPS rely on observed and not forecast demand. Signals at different points in the process are used to determine when more parts are needed. To illustrate the concept simply, imagine a parts bin on the factory floor with a Kanban card (signal) inside that carries part identification. When the bin is empty, the bin and the card are taken to the factory’s store for replacement. The factory store replaces the empty bin with a full one containing its own Kanban card. The factory store then presents the empty bin and its Kanban card to the appropriate step in the supply chain for replenishment.
In such a system, as long as there is one spare in the factory store, the process will never run out of needed parts and supply costs are only incurred when they’re actually necessary. While it may not seem revolutionary at first blush, it turns out that it is. This subtle shift in thinking can have a dramatic impact on efficiency and waste.
The general flow of Kanban would look something like this:
By now, you’re probably thinking:
“This is all well and good in a factory production line, which is a very linear process where the product moves from one assembly stage to another in orderly fashion and once the product moves form point A to point B, it doesn’t come back (provided quality is satisfactory when it arrives at point B). But software development doesn’t always operate in a linear process.”
It’s true that flow is often non-linear with software development. It’s not always a clean handoff from elaboration to development to testing. Sometimes design and development are happening in parallel, for example. Plus, we’re talking about labor and not physical, raw materials.
However, Kanban is in use in lean non-manufacturing environments and, in fact, Kanban has already been adopted in some agile software development environments. That’s likely because Kanban is relatively easy to adapt to specific environments because there aren’t a lot of rules.
Kenji Hiranabe1 succinctly lists the rules of Kanban as:
And, in fact, Toyota’s TPS itself has only six very simple rules:1.
In non-manufacturing environments, the primary purpose of Kanban is to facilitate efficient workflow. In manufacturing it’s about having the right part in the right quantity at the right time. This is as opposed to producing based on guesswork and estimation. It’s about being lean. Very lean.
The real question then, is “Does Kanban conflict with Agile concepts/principles?”
The best answer might be, “In some ways, maybe. In some ways, maybe not.”
Over the last several years a large number of Agile practitioners have begun to include thinking from lean manufacturing in their Agile approaches, thanks to trailblazers like Tom & Mary Poppendiek in their book Lean Software Development. But Kanban, at least as discussed thus far, seems to break the primary rule of today’s common agile practice: the fixed development time-box. Kanban systems are continuous, not iterative, yet both exist to promote workflow efficiency.
In his article, Kanban Development Oversimplified, Jeff Patton illustrates some of the conflicts between Agile and Kanban. With Kanban development:
Implementing Kanban in an Agile environment might require a bit of ‘shoehorning’ to make it work. But Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum. In this way, they certainly seem complementary.
At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process. And, just as Agile has evolved into several different flavors over time, like XP and Scrum, it’s not a stretch to imagine Agile-Kanban hybrids like Scrum-ban just might create a synergy for software development that neither could achieve on its own.
I’ve laid the groundwork by providing some context on the possibility of using Kanban in an Agile software development environment. Just as I think different forms of Agile shouldn’t be seen as conflicting but as complementary, I also think it’s important to keep an open mind and consider that Kanban and Agile have the potential to be complementary and not contradictory. The subtle shift in lean thinking turned out to be revolutionary in classical production, and it may just have a significant impact in the world of agile as well.
In Part 2 I’ll take a look at how Kanban is currently being adopted in Agile environments and the key tradeoffs that might result.