Written on a phone. Expect typos.
I’m presently reading Taiichi Ohno’s inimitable Toyota Production System: Beyond Large Scale Production, which is such a pleasant read. It’s crisp and concise with unique insights into the development of the keys ideas of TPS. It also serves as a poignant historic of the founders for the Toyota empire.
Ohno gives a clear argument on how he arrived at the two pillars of TPS: jidoka (autonomation) and just-in-time (JIT). Autonomation is more than mere automation; it is intelligent automation - that which, not only performs some tasks on its own, but does so autonomously, able to detect out of standard operation and take corrective action. JIT, on the other hand, is all about flow; that is, matching the rate of component production in order to eliminate overproduction, which is the most pernicious form of waste.
My curiosity, however, is to determine how to apply these concepts in developing software. Autonomation is easy but over really struggled to wrap my mind around how to accomplish JIT in software… until now.
Similar to Ohno’s quagmire, the solution is quite simple: begin at the end. In Ohno’s case, he envisioned the correct approach to a pull system in which the later stages of production pull inventory from earlier stages of production. This is where kanban comes in. Kanban are the means by which earlier stages of production obtain information from later stages. A card for every unit of inventory is dispatched upstream and it is the aggregate of such cards that firms the basis of production. Actually, this should proceed almost instantaneously so that for every unit of final output it should be possible to very accurately determine what the full complement of inventory required will be. There is a downside to this approach: huge swings in downstream demand can lead to strains. This is where Ohno’s third truck comes in: production levelling. I am yet to fully understand how he resolves this. When I do I’ll be back with more.
So, how would one go about applying JIT in software?
Its actually quite simple, really. Just as in manufacturing, the best guide for production is from the final stage of production: market demand. Nothing should be produced until actual demand is discerned. Then for every order, the underlying components should successively be assembled leading all the way to the most foundational components.
In practice, this takes the following form. If the project is a greenfield project then sufficient time should be devoted to genchi gembutsu, observation of the actual users. This is design and its an eminently collaborative exercise intent on exposing every single latent need that domain experts typically take for granted. Alternatively, if the project is covering familiar ground then building wireframe prototypes for validation would suffice. Once some design stability is achieved, (no more surprises) then it is time to engineer the solution. By engineer I don’t mean build; rather, I mean evaluate the technical feasibility of the project. It may be necessary to revisit the design stage but no surprises should arise though some compromises may result. Once the design and engineering are complete construction can begin and again this will be a last-to-first approach. What are the significant design components that can be produced independently and how much attention do they require? This is repeated iteratively all the way to the beginning until the basic units of work are clearly outlined.
This is the first form of this idea in my mind. A lot more refinement is needed. Nevertheless, it is yet another mail in agile’s casket. Agile turns this on its head with a view of getting something into production as soon as is practically possible. To say that agile is lean is a complete misunderstanding of what lean actually is.