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

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica