Toyota Production System

This is a mish-mash of analogies that came to mind as I read Toyota Production System (TPS), about how TPS is similar to Extreme Programming (XP). Kent Beck has spoken about how deeply reading TPS impacted him when he was coming up with XP, so in a way, I see XP as one of the most faithful attempts to apply the Toyota Way to code. I have read that from a TPS perspective, “lean” and its descendents often neglect the human side of Toyota process. I think XP does not.


XP: Sustainable pace. Programmers should work regular hours, and not sprint to make deadlines. This allows predictability at the project level, and prevents burnout.

TPS: Production leveling. Factories and workers should not mindlessly overproduce – they should aim to produce exactly the required amount. This is done by setting a steady pace of work that allows the worker and factory to reach the desired outcome without wasteful starts and stops. Workers should also not be overworked or overburdened (muri).


XP: User-driven development. Continuous deployment. All features should be “pulled” out of the user, and code should go from development to acceptance to production very quickly, on the order of multiple times a day.

TPS: Just-in-time production. Rather than encouraging factories to massively produce their particular part, and storing excess inventory in warehouses, the company as a whole should only work to produce the bare minimum necessary to fulfill business needs.


XP: Testing. Writing unit tests to prevent accidentally breaking functionality.

TPS: “Autonomation”, or Jidoka – automation with a human touch. Inventing and using machines that are smart enough to stop when they detect a mistake.


XP: TDD, and refactoring. Best practices that depend on discipline that improve the code. Constantly improving the code, and leaving it in a better state than before.

TPS: 5S. These are seiri (sort), seiton (straighten), seiso (scrub), seiketsu (standardize), shitsuke (sustain). Housekeeping, standardization, and reflecting on those standards leads to kaizen, or organizational improvement.


XP: Continuous integration (CI). Having a CI monitor display in a central place whether the build is working (tests are passing).

TPS: Andon/visual management. The next step to autonomation is to have the state of all the machines visible from a central place for management.


XP: Pair programming. Code is continuously reviewed by two people as they write it together. Pairs also keep each other focused, a form of peer-to-peer visual management.

TPS: Modified assembly lines/visual management. Instead of having a linear Ford-style assembly line, TPS grouped workers together and had them work more collaboratively.


XP: Full-stack. Everyone on the team is responsible for every aspect of the code. This lowers the “bus count” (or “lottery count”) of the project, which is how many people can get hit by a bus (or win the lottery) before the project would fail. You want a high number to lower the risk.

TPS: Modified assembly lines. Toyota realized that it is more efficient for workers to perform an entire task end-to-end, rather than to perform a single repetitive motion over and over again. Even for something as simple as the receptionist folding letters and placing them into envelopes, they timed and found it faster to fold and stuff entire letters at a time, than to fold all the letters, than to stuff all the letters.


XP: Respect. This is one of the values of Extreme Programming, and perhaps one of its deepest.

TPS: Respect for people. This is one of the two pillars of “The Toyota Way”. This involves treating employees as intelligent, valuing their humanity, and not exploiting them.


One of the ideas I struggled with is that the mappings between XP and TPS seem to be many-to-many. Pair programming is both a form of visual management and a restructuring of the work environment. Sustainable pace is both production leveling and respect for people. And “poke yoke” (mistake-proofing) can apply to syntax highlighting, linters, tests, guard clauses, and ad-hoc scripts that run tests before shipping. The result is that trying too hard to apply TPS to programming in a literal sense leads to misconceptions. To make this simpler, I kept the XP side of the equation to be only one idea at a time, while allowing TPS to be multiple and duplicated.

And of course, programming is much less car manufacturing than painting :).

Home