A few weeks ago, Nigel Thurlow posted a provocative piece on LinkedIn about the authenticity of Kanban in software development. Specifically, he refers to the 6 Rules of Kanban. Read that before continuing here!
I normally avoid getting into deep discussions on social media. It’s generally not constructive or productive. However, I did have a call with Nigel as his post did trigger a reaction. As is usually the case when this happens, I think it’s fair to say that we agreed on more than we disagreed!
While its nearly 7 years since I last blogged about Kanban explicity I wanted to share my reflections on the conversation.
Metaphor
One of the things we agreed on was that when we talk about Kanban for Software Development, we are using a metaphor. The name Kanban for software development came from an observation by Don Reinertsen that the development process used by a team at Microsoft was “like a kanban system” (or words to that effect). The original Kanban team did not intentionally set out to implement a Kanban system. Rather, they were actually applying Theory of Constraints, and its just that they ended up with something like a Kanban system.
Further, the original terminology used by the Kanban community in the very early days was Virtual Kanban. This recognised the fact that there was no physical token to send a signal “upstream” and create a pull system. Instead, the signal was virtual, generated by the amount Work in Process falling below a defined limit. (We used to joke that “Kanban Sucks” because the vacuum created by work moving forward sucks new work in. In other words, it’s the suck that creates the pull).
However, the community quicky settled on Kanban as the shorthand it used. People stopped using the work Virtual due to its addional verbosity. As an example, the original Yahoo! mailing list was called kanbandev.
Rules
The Kanban systems designed and implemented by Toyota were context-sensitive so this all makes sense. They were used in a manufacturing context that is very different to a software development context.
Given that, what do we do with the 6 rules of Kanban, as defined in Taichi Ohno in his “The Toyota Production System“? There is a good explanation of them here. As a reminder, they are:
- Don’t Send Defective Products to the Subsequent Production Process
- The Subsequent Production Process Comes to Pick Up
- Only Produce the Amount Picked Up by the Subsequent Process
- Reduce Fluctuations
- Kanban Is a Means of Fine Tuning
- Stabilize and Rationalize the Production Process
New Rules
I’ve found a few variations online, but they all seem to maintain a language that seems quite specific to manufacturing, so I wondered what those rules would look like from a software development perspective.
The first three are the ones that most obviously refer to a production process. Software development is more about work moving between workflow stages than individual products being picked up by separate processes. The last three remain largely relevant, with just a minor reference to the production process.
Given that, I propose the new 6 Rules of Kanban for Software Development could be:
- Don’t Send Defective Work to a Consuming Workflow Stage
- The Consuming Workflow Stage Pulls the Work
- Only Progress the Amount of Work Pulled by the Consuming Workflow Stage
- Reduce Fluctuations
- Kanban Is a Means of Fine Tuning
- Stabilize and Rationalize the Workflow
Of course, Nigel’s primary question is still valid. Does your Kanban System follow these rules?
And yes, this is just a gratuitous excuse to use more Dua Lipa artwork after my post on Nostalgia.
[…] The New Six Rules of Kanban For Software Development (Karl Scotland) […]