The NUMMI Factory — A Parable About Software Development

What We Can Learn from other Industries

Software development is not difficult because of the technical challenges, but because so many people are involved. A story about a car plant shows how other industries deal with these challenges and what they have learned.

Software development can learn from other industries. A story about a car factory serves as an example. General Motors (GM) opened the factory in 1962 as Fremont Assembly. Unfortunately, it quickly gained a very bad reputation: the workers are said to have been the worst in the entire US automotive industry. Alcohol was as common as unexcused absenteeism, so that sometimes production could not even start at all. Sometimes, the workers even sabotaged production. Management didn’t care about the workers' perspective. And of course, as so often in mass production, it was all about quantity and not about quality at all.

Toyota Production System

The entire workforce was fired in 1984. GM and Toyota set up a joint venture to continue production in the factory. Of course, they had to hire workers, which was difficult. In the end, 85 percent of the old GM workforce worked in the factory. Some of them were sent to Toyota Japan to learn the Toyota production system. In the end, the plant achieved the same productivity and defect rate as Toyota’s plants in Japan, and significantly better results than GM in the US.

The Toyota production system is based on values such as continuous improvement, respect for people, and long-term thinking. At the NUMMI plant, the values have also been implemented: The focus was on teamwork and quality. All employees - whether in management or production - wore the same uniform, had the same parking spaces, and a shared cafeteria. There were also no layoffs, a program to suggest improvements, and consensus decisions.

Jidōka

An important part of the Toyota production system is Jidōka. It stands for “autonomation” i.e. “automation with a human touch” or “intelligent automation”. If anomalies occur, the machine stops. The goal is not full automation. Then the machines themselves would have to be able to deal with anomalies. But this can hardly be achieved cost-efficiently.

Instead, the operator identifies the core problem and eliminates it. To do this, he or she can stop the production line and request help from his or her colleagues. Production stoppages can cause considerable costs. Of course, there are measures to avoid this, but the possibility of stopping production clearly shows how important the goal of quality is.

How the Story Continued…

In 1998, despite the joint venture, GM managed to implement the ideas of the Toyota production system in other plants only in exceptional cases. GM ended the joint venture in 2009 and Toyota finally closed the factory in 2010.

That sounds like the end of it all, but shortly afterwards Tesla opened its plant there and Tesla still owns the plant. And so the revolution of electric mobility started from this factory.

Lessons Learned

Several lessons for software development can be derived from this story:

  • The Toyota production system is based on a different culture. It leads to better quality, productivity, and reduction of inventory. Some automakers have tried to manage quality directly and have therefore confused cause and effect. The culture leads to the success of the Toyota production system. This results in better quality. The same applies to software development processes such as agility or continuous delivery: if the culture changes, there are advantages such as better productivity or less errors as a result. A focus on techniques often obscures this view.

  • It is difficult to transfer a culture to other organizational units. Despite the joint venture, GM has basically failed to copy the success in its own factories. But on the other hand, people who have previously worked in a different culture can learn and live a new culture. This has allowed the NUMMI workforce to evolve from very low productivity to very high productivity.In principle, it is therefore conceivable to fundamentally change the culture of a software team and thus improve the results.

  • Jidōka shows an important element of the Toyota production system. Errors should become obvious and then be completely eliminated. Techniques such as agility or continuous delivery are aimed at testing software and features as often and as quickly as possible and bringing them into production. This makes it possible to detect errors faster, which can then be eliminated. So if problems become obvious through the process, this is an expected result and there is the possibility to react and improve.

  • At the same time, Jidōka shows that perfect automation is not necessarily a sensible goal. This also applies to Continuous Delivery. What is important, however, is how to deal with automation problems and then eliminate them.

  • Jidōka also shows what positive effects it has if every employee can work on goals such as quality through appropriate measures and, if necessary, stop production at the same time. It is not just a question of the employee being able to solve problems so effectively. But the enterprise expresses also confidence in the workers, which improves motivation. Such measures are also conceivable in software development.

The NUMMI factory is not a random example. Agile software development is based on lean production and the Toyota production system. Agility from this area has taken over the essential concepts, so that a look at examples from production is worthwhile.

tl;dr

The NUMMI factory shows that culture can be decisive for the success of a company, but it is also difficult to change it. The Toyota production system practiced in that plant is essentially a change much like agile software development.

Header photo by Leo Fosdal on Unsplash.

TAGS

Comments

Please accept our cookie agreement to see full comments functionality. Read more