Spence Green

The Toyota Production System (TPS) was the progenitor for a variety of change-oriented manufacturing techniques. Six-sigma, Lean, and other such constructs trace their heritage to TPS. Because Agile methodologies were influenced by “lean” thinking and an abhorrence of “Big M” processes, they too have eastern roots. For me, the allure of Agile methods, regardless of flavor, has always been the recognition of software as a human act: Programmers are not automata on an assembly-line tacking trunk lids to mechanical foetuses. Incidentally, the Japanese reached the same conclusion decades ago, as described by Teruyuki Minoura, a Toyota executive:

An environment where people have to think brings with it wisdom, and this wisdom brings with it kaizen (continuous improvement),” notes Minoura. “If asked to produce only one unit at a time, to produce according to the flow, a typical line worker is likely to be flummoxed. It’s a basic characteristic of human beings that they develop wisdom from being put under pressure. Perhaps the greatest strength of the Toyota Production System is the way it develops people.

There can be no successful monozukuri (making thing) without hito-zukuri (making people). To keep coming up with revolutionary new production techniques, we need to develop unique ideas and knowledge by thinking about problems in terms of genchi genbutsu. This means it’s necessary to think about how we can develop people who can come up with these ideas. As our operations become increasingly global, there’s also a need to think how to implant the Toyota DNA in our overseas personnel.

This is why software development at large, legacy corporations can be so stultifying. In his prescient IEEE Computer article, Barry Boehm labels the “That’s How We’ve Always Done It” (THWADI) attitude as a paralyzing disability in the rapidly changing software world:

There will be a lot of tensions between people and organizations rapidly adapting to change and those who prefer not to. A good example nowadays is the interaction between software developers trying to be adaptive to change within fixed-price, build-to-specification software contract structures determined by administrators practicing THWADI (That’s How We’ve Always Done It).

Of course, some THWADI is good. We will need to separate obsolete practices from enduring principles that need to be conserved.

Some other implications for software engineers’ careers are that learning how to learn will be more important than learning things….

Software teams that grasp this reality and its implications “look” and “feel” different from the moribund organizations that churn out the same old Micro-crap. The Guardian’s web team is a recent example of the former that comes to mind.