Was Original Kanban “Agile?”

Matrix with four columns and cards in various states of progress across themIn a recent social media discussion, someone stated that the founder of Kanban would not consider it “agile.” I don’t doubt that, and I know some Agilists say Kanban was/is only Lean and not agile. My belief that Kanban is an agile method is based on the way it is taught for use in offices today. That said, I got curious, and I like to test my beliefs against evidence, so I ran a crude experiment.

First I identified overlaps in lists of concepts from three seminal works on business agility: the 45 “prescriptions” and their categories from 1987’s Thriving in Chaos (TC); the 18 “characteristics” from the 1991 “Agile Strategic Manufacturing Forum” (AF); and software’s Agile Manifesto (AM) from 2001. Then I re-read the first journal article describing Kanban, 1977’s “Toyota Production System and Kanban System: Materialization of Just-in-Time and Respect-for-Human System.” I looked for phrases relevant to each concept, mindful to avoid the common practice in politics (and movie ads) of pulling quote snippets that change the original meaning.

Agility is made up multiple concepts, so whether an organization is “agile” is not binary: Most are some mix of practices in a range from fully “traditional” to fully “agile” management. I adopted an approach used by social scientists when dealing with a continuum, like “introvert” to “extravert.” Almost all of us are a mix of traits from those two extremes, so a 51/49% split does not make you either. Typically a scientific study would only label you an extravert if you scored at least 67% to that side, if not 75%. Since my measurements here were rough and subjective, I adopted the higher standard. I hypothesized Kanban was more agile than not, but not an agile method—that is, it would not reach the 75% threshold.

I think there are 13 places where at least two of those three agile lists overlap and the third doesn’t disagree. Here are my labels for those concepts in bold, followed by example quotes or terms from the lists, and finally a related quote from the Kanban article in italics if I found one (either supporting or opposing the concept):

  • Response to Change—The “Agile enterprise… thrives on continuous and rapid change” (AF); “Responding to change over following a plan”; “Welcome changing requirements… Agile processes harness change” (AM); “Learning to Love Change” and “Achieving Flexibility” categories (TC): schemes adjustable to conform with changes due to troubles and demand fluctuations.
  • Training as a Strategic Tool—“Continuous Education” (AF); “Train and Retrain” (TC): “separating the workers from the equipment by assigning a worker to multiple equipments (sic), which implies retraining.
  • Focus on Customer Satisfaction—“Customer Responsiveness” (AD); “satisfy the customer” (AM); “Total Customer Responsiveness” category (TC): “Final assembly lines of Toyota are mixed product lines” with output driven by monthly demand numbers.
  • Integration with Suppliers and Customers—“Dynamic Multi-Venturing” (AF); “partnerships with suppliers/distributors/customers” (TC): “a system that provides production schedule to all the processes and suppliers as well as its alterations and adjustments by real time control.”
  • High Employee Satisfaction—“Employees Valued” (AF); “trust them” (AM); listening, incentive pay, employment guarantees (TC): “specially important to Japanese companies that have (a) lifetime employment system”; “a system of respect for human(s)”; “the frequency rate of injury at Toyota is low.”
  • Radical Empowerment—“Empowered Teams/People” (AF); “self-organizing teams” (AM); “Self-Managing Teams” (TC): “making up lines that do not require supervisory operation”; “workers can actively participate in running and improving their workshops”; “Any employee at Toyota has a right to make an improvement on the waste he has found.”
  • Full Transparency—“Information Accessible” (AF); “Business people and developers… work together” (AM); “Involve Everyone in Everything” (TC): Not addressed.
  • Flexible Architecture—“Open Architecture” (AF); “best architectures” (AM); “Manufacturing (as a) Marketing Weapon” (TC): Not addressed.
  • High Quality Design—“Optimum First-Time Design” (AF); “Continuous attention to… good design,” “best designs” (AM); “Pilots” and “Fast Failures” (TC): Not addressed.
  • Defect-Free Output—“Quality over Product Life” (AF); “Continuous attention to… technical excellence” (AM); “Provide Top Quality” (TC): “‘make the equipment or operation stop whenever an abnormal or defective condition arises.’”
  • Faster Output—“Short Cycle Time” (AF); “Deliver… frequently” (AM); “Pursue Fast-Paced Innovation,” “Support Fast Failures” (TC): “shorten the lead time from the entry of materials to the completion of vehicle”; “reducing set-up time down to 10 min. at (the) 800 ton-line pressing hood, fender and others, while it used to take 1 hour.”
  • Enterprise-Wide Agility—“Total Enterprise Integration” (AF); “Decentralize Information, Authority, and Strategic Planning” (TC): Not addressed.
  • Clear, Motivating Vision—“Vision-Based Management” (AF); “Our highest priority…” (AM); “Develop an Inspiring Vision” (TC): Not addressed.

So Kanban in its original form supports eight out of 13 agile concepts, or 62%. However, the other five were not opposed in the article; they just weren’t addressed. Of those, I think three relate to product design or broader management, whereas Kanban was aimed at team-level assembly operations. Remove those three, and one could argue that original Kanban was 8/10 or 80% agile at the team level, contrary to my hypothesis. At the very least, it was more agile than not. So it seems valid to state today’s office version of Kanban, if correctly implemented—with WIP limits, column exit definitions, etc.—is both Lean and an agile method.



Tell the world: