This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Agile Beyond Software: GM Case Study
There is an ongoing debate about whether Agile is just for software or if it can be extended to other industries. I for one believe the Agile values and principles can be applied beyond software, but, in a recent discussion about this, a colleague raised a concern that some of the principles would be difficult to apply for some industries. The principle in question: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
The thought here is that manufacturing industries have a high cost for changing once production has begun. This is true, it can be costly to change since production has to be stopped, parts changed, processes reconfigured, delivery would likely be delayed and there is cost in correcting any issues in products already produced. However, one cost that is often dismissed is the cost of not changing.
Let’s consider the recent case with GM and the ignition switch malfunction. According to several reports GM has issued a recall on about 2.6 million vehicles to repare the faulty ignition switch. For arguments sake, let’s just pretend that the cost of the part and the cost to have a post production mechanic replace it is the same as the original. That means for every replacement, they are paying double the original cost. Then there are the costs for the accidents caused by the malfunctions, and the biggest cost, the cost of lost lives. How do you put a price on that?
So, I think we can safely surmise that GM would have spent less money had they replaced the part when they found the issue. What we should consider next then, is whether they could have replaced it, even late in development. According to the graphic in this NBC article (http://www.nbcnews.com/storyline/gm-recall/infographic-when-did-gm-know-it-had-ignition-switch-problem-n68611) provided by Ronnie Polidoro, GM first found out about the issue in 2001. Apparently they also dismissed a partial fix in 2005. Now it’s 2014 and they have finally issued a recall.
It seems clear to me that, in this situation, accepting the change in requirements would have been easier and less costly than going with the chosen path. It certainly seems that it would have at least been in the customer’s best interest to do so.
What are your thoughts? Do you think Agile principles could be applied here? How about Agile beyond software? I look forward to your comments.