Skip to main content

Et tu, Toyota?

I was gripped by anxiety today when I found out that Toyota is recalling another 1.13 million vehicles, and even more if you count Canada.

I worry for Toyota owners of course, American and Canadian alike.  But professionally, I feel even more worried for us advocates of lean and agile principles who have depended on Toyota to provide a one-word motivation to our audiences.  For decades, Toyota has been our hero, and even if we quickly disavow the company now as having any major role to play with lean, the questions about Toyota’s quality and processes are going to come back to haunt us, and we need to be prepared.

So today’s recall news brings agile presenters (and would-be Toyota owners) together to ask three new common, and newly urgent, questions:

  • Is there actually a problem?  Do friends let friends buy Toyota any more?  Or is this nothing more than an emotional media circus?
  • If there is a problem, was it caused by Toyota’s adherence to lean principles?  If so, what do we need to adjust in our teaching of lean?  If not, what do we need to do in describing how Toyota fits into our world view as agile/lean advocates
  • What should our go-forward plan be, as consumers, and as advocates for lean/agile principles, in light of this year’s Toyota-related events?
Is there a problem? 

Well, as agilistas of all races, colors, creeds, and sexual orientation are prone to say, “it depends.”

Thesis 1:  this is media hype, like what happened to the Audi 5000 ten years ago.  Jamie Flinchbaugh provides this excellent summary of the journalistic and blogosphere debates around the Toyota Affair.  He points to a valuable article by Business Week’s Ed Wallace on how media coverage of this type of incident has fanned the public’s tendencies to prefer the hype around an emotional story to verifiable facts, which tend to be less interesting.

Thesis 2:  Toyota has an actual long-term problem with their electronic throttling system.  Today’s recall supports a theory the New York Times advanced already in February that Toyota has had problems in their electronic throttling system design which go back to 2002 or even 1998, and what we saw in 2010 was not just driver error, oversized accelerator pedals or loose floor mats.  The smoking gun here is that when the first recall broke in January, Toyota brought consumers in to have their accelerated pedals shortened and mats tightened, they also did a quiet computer reflash on the vehicles to allow the braking system to override the throttle, which it didn’t previously do.

The ABC story which provided the most details about the throttling problems, however, included footage which was clearly doctored, which suggests that whatever the truth of the matter, hype is part of the equation as well.

If there is a problem, was it caused by Toyota’s adherence to lean principles?

Let’s assume there is a long-standing problem with Toyota’s electronic throttling system.  Or even a shorter-standing problem with floor mats.  To what extent should we blame lean?  The Wall Street Journal’s headline article on January 30 discussing the Toyota affair was entitled “How Lean Manufacturing Can Backfire.” 

Mark Graban of LeanBlog observes that the WSJ seems to make frequent ill-informed attacks on agile/lean techniques, particularly “just in time” manufacturing, and if he's right, this is no exception.  If, indeed, the use of large quantities of standard foot pedals was the root cause of the problem, as they explain, that’s hardly a manufacturing choice Toyota can be said to have made from lean principles, which calls for small, quality batches.

Moreover, if Toyota knew about problems with their foot pedals, floor mats or electronic throttling systems and didn’t act on them, then Toyota was definitely NOT following fundamental principles of agile and lean that call for “failing fast” and “building in quality.”  Toyota is famous for providing a literal “emergency stop” cable which could be pulled by any person on the production line who finds any fault in the product, and which should result in an immediate halt to production until the problem has been fixed.  As Gad Allon says eloquently, there were enough quality problems being reported to Toyota as early as 2002 for someone to have done something much earlier.  He calls this “The Andon Cord that Wasn’t Pulled

Toyota, in fact, persists in denying that there’s a problem with the throttling system, even while issuing soft fixes on it, including in this webinar which provides Extreme Scientific Detail.

So Where Does That Leave Us?  Can We Still Use Toyota Quality to Motivate Agile Converts?  And Should We Buy Toyota?

Any long-term admirer of Toyota and what it stands for may be disappointed in the recent quality problems with the cars, and with what seems like clear violations of the agile/lean philosophy that should have prevented these problems.  However, as many others have said quite eloquently, Toyota is still quite exemplary in most ways, under most circumstances, compared to the competition, particularly when it comes to using lean processes to leverage generally higher quality. 
  • Long-time Toyota watchers predict that Toyota will continue to beat out their competition in finding and removing these defects, in the long run.
  • And as Marty Larivieri says, the fact that the WSJ is using the example of Toyota to show that lean principles lead to lower quality could certainly mean that “apparently someone who is too young to remember the Chevy Citation and its X-body siblings is now old enough to write for a major newspaper.”   
All the same, in my slides, I am temporarily going to start talking about Toyota the way people talk about their favorite rock band, and explain “I only like their old stuff.”

Comments

  1. Maybe the media hype was called to compensate for the numbing news of war overseas. Citizens had to be scared once more so there was a need to sharpen the scare-and-reign tactics ...
    Anyhow, I believe they are unrelated and that the lean implementation might have been infected by contemporary thought. We should always look out for the new guys who mix best practices and methods to the point of failure. Some things are born good and don't follow trends and fashion ...

    ReplyDelete

Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …