Process Doesn't Transfer

Why process frameworks don't work.

I tell this story periodically, but it seems like it’s time again:

General Motors ran an automobile manufacturing plant in Fremont, California, that was one of the worst in the country. Accident rates and defects were astronomical. Absenteeism was through the roof. They decided to fix that through a joint venture with Toyota called NUMMI.

Toyota came in and implemented TPS (Lean), and the turnaround was dramatic. Within a few months, NUMMI was a model of perfection. Defects fell to almost zero, as did absenteeism. A critical part of that turnaround was giving the teams control over their own practices and processes. Toyota did NOT install the workstation-level practices that worked for them in Japan. Instead, the teams were given strategic goals, and it was up to each team to decide how best to fulfil them. The other critical factor was Kaizen—continuous improvement (and by “continuous” I mean “continuous.” Every minute of every hour of every day. None of this once-every-two-weeks retro stuff. Teams at various workstations coordinated as needed, but multi-team retros occurred only when a defect was detected, and someone pulled the Andon Cord, thereby stopping that part of the line until global processes were changed so the defect couldn’t happen again. The teams implemented any necessary changes.

Part of TPS is to document those practices. The good General took that documentation back to Detroit, plonked it on management’s desk, and said, “You have to work as described in these docs.” That was an utter failure. Pretty much every metric got worse. The same processes and practices that worked wonders in Freemont did active damage in Detroit.

What GM didn’t get is that the key element that made things work so well in Fremont was team autonomy—the fact that each and every team developed and was responsible for its own process and practices. The actual processes the teams came up with were much less important. Process does not transfer. There were universal guidelines (e.g. Kaizen), but nobody told the teams how to do their work.

Now, consider something like Scrum. Like NUMMI, Sutherland and Schwaber mixed a lot of Lean thinking into what they were doing. The first, autonomous Scrum team came up with a process that worked for them, and they improved. However, PROCESS DOES NOT TRANSFER. Team autonomy—the team’s ability to define how it works—is the critical element. Any organization that just mindlessly follows that first (or any other) Scrum team’s documentation will get the same results that GM got in Detroit. Failure. (Or at least no real improvement).

Worth thinking about.