[Off Topic] Watch Out for Kanban-butt
For some reason, recently many people have been discussing and evangelizing Kanban. This is getting particularly annoying to me. Be very careful: just applying the Kanban tool as if it were a methodology isn’t right. This tool was created and spread by Toyota, decades ago, within a larger methodology known as the Toyota Production System (TPS), created by the great Taiichi Ohno.
As I said in a previous article, agile methodologies have the same foundation. To understand TPS it’s good to return to the original literature, and one of those sources is the book A Study of the Toyota Production System from an Industrial Engineering Viewpoint, by Shigeo Shingo, published in 1996. In the Preface he says:
Many believe that when implementing a new system, only “know-how” is needed. However, if you want to succeed, you must understand, as well, “know-why”
With the know-how, you can operate the system, but you won’t know what to do if you encounter problems under conditions different from the usual. With the know-why, or “knowing why,” you understand why you have to do what you’re doing, and thus face changing situations.
Specifically about Kanban he says:
The biggest problem I encountered while studying TPS from an Industrial Engineering viewpoint is the fact that it’s often considered synonymous with the Kanban system. Mr. Ohno writes:
- TPS is a production system
- The Kanban method is a technique for its implementation
Many publications are confused on this issue and offer an explanation of the system, claiming that Kanban is the essence of TPS. Once again: TPS is a production system, and the kanban method is merely a means of controlling the system.
Superficial analyses of TPS give special attention to the kanban method because of its unique characteristics. Consequently, many people conclude that TPS is equivalent to the Kanban method.
A Kanban method should only be adopted after the production system itself has been rationalized. That’s the reason this book repeatedly insists on the fact that TPS and the Toyota method are separate entities.
I should add that 90% of Toyota’s excellent management performance was attributed to TPS itself, and only 10% to the Kanban method — a clear demonstration of the greater importance of TPS.
To recap: Shigeo wrote this in 1996. Impressive how more than a decade later we’re still making the same interpretation mistakes.
Just as with the Agile Manifesto, the Toyota System also has a set of 14 principles, known in the West as The Toyota Way. And just like in Agile, it isn’t enough to do Sprints, put post-its on the wall, and say it’s Agile. To follow the Toyota method, it isn’t enough to use Kanban.
To understand Toyota, it’s mandatory to understand the Toyota Way, and one of the best books to start understanding it is The Toyota Way by Jeffrey Liker. Besides that, if you’re really interested and intend to take it seriously, you need to understand what Toyota’s management revolution was, narrated in the classic book The Machine That Changed the World by James Womack.
If you’re still not convinced, still in Shigeo Shingo’s book, at the conclusion of the chapter on Kanban he says:
Kanban systems can only be applied in factories with repetitive production. (…)
Kanban systems are not applicable in companies with non-repetitive project-based production, where orders are infrequent and unpredictable.
The type of production most likely to benefit from Kanban is that which uses common material transformation processes.
As a tip: software development is a non-repetitive task. Still, TPS principles are still very applicable if the know-why is clearly understood.
The Toyota method is more generically known as Lean Manufacturing. The best work adapting Lean to the software world is the book Lean Software Development, written by Tom and Mary Poppendieck. Before lightly talking about Kanban, it’s mandatory to read those works — otherwise it’ll just be one more tool that will fail, and we’ll have a wave of Kanban-butts.
Everything that comes easy goes easy. It “seems” easy to implement Agile. It “seems” easy to implement Kanban. There’s no free lunch. Take things superficially and don’t expect anything beyond mediocre results. That’s how things work.