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.”

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…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

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…