Agile for Autos

I was speaking the other day with software executive, who shall remain nameless (except to say that I really like the company he founded, it is staffed with really great people, and I generally like the products they produce) about product development. As is often the case in Silicon Valley, I find that software executives and engineers narrowly define product development in terms of the Agile Framework. What was so striking about this fellow was just how narrow his view was – like he couldn’t even fathom that products could be developed any other way. It was almost like he couldn’t imagine a product other than software! As I tried to explain how consumer telematics products are developed, he was genuinely perplexed. This was mildly alarming to me as I know this company is seeking to launch their software products into connected vehicles, something I have years of experience doing. After being vexed at his unwillingness to view the world outside of Agile, I politely ended the conversation with well wishes. And I meant it.

But seriously, Google maps updates are even annoying on my computer.

If this company actually landed an OEM Big Fish, and all OEMs are big fish compared to the size of this company, they are about to enter a world of pain.

I have been the “monkey in the middle” between Agile development, Waterfall, and good old fashioned hardware development. I have had to help develop the methods and messages for selling connected products. If you enter this space, be flexible, be open-minded, and know that one way is not the only way.

Agile is really, really, really cool. My husband is a skittle-eating coder, one of the best actually, and I’ve seen the power of Agile over his decade of developing software products. The principals of agile are sound – satisfy the customer through early and continuous delivery of software, harness change for competitive advantage, deliver working software frequently, etc. They work great for products that have consistent release and update cycles. And they work especially great when end user’s expectations are of constant updates and improvements.

Which is where the problems lie when contemplating Agile for Autos. I am not saying that it cannot be done nor be done well. All I have to do is look to Woody Arnold at Aha Radio and see the amazing and talented group of engineers he runs and look at the incredible product, Aha Radio, itself as an example that it can be done. BUT, Aha Radio is one of those consumer products that users expect to change and get regular update – not just bug fixes and product improvements, but full scale innovations to boot.

There are certain vehicle features that customers do not expect to get updated often and I would argue, would be very annoyed with an Agile-type release cycle. Take navigation and maps for example. I am an avid of user of both. I use predominately use Google, but also use Apple maps on my iPhone. I almost exclusively use Google on my computer. Now, in all honesty, I have a terrible sense of direction so, I spend a lot of time preplanning trips. I like to understand where I am going, what is around me, and to be prepared. The majority of the time, I am not comfortable figuring it out on the ground or behind the wheel. So when Google radically updated their maps, I was psyched and dismayed. Psyched at the improvement on landmarks and dismayed that I couldn’t search around a specific location for categories of destinations, as was previously available. There were a ton of features I had come to rely upon that Google either simply removed or had not yet added back, like mapping a route with numerous way-points. I had faith that Google would add even better versions of the features I loved and show me new features I could grow to love (Waze anyone?!) I wrote numerous comments to Google to “help improve the system” and I knew that the Agile scrums would push out code that while not perfect, would have core functionality, and improvements would follow over time.

But seriously, Google maps updates are even annoying on my computer. The ability to locate an address on a map and the inability to then search for “what is around here” is a real problem for me. I relied on that feature and it is gone.

I couldn’t imagine that happening to my maps in my VW. I would be PISSED if the system changed under me with features removed. And then I would go to my dealer and demand they fix it.

Like it or not, I have developed a muscle memory to use of my crappy in-vehicle maps. There are things I would like to update, without a doubt. And updating it wirelessly, over the air, would be great. I may even pay a nominal amount of money for an upgraded system, say $60. But I would want the update to be more whole and consistent, allowing me to learn the new system in its entirety. I do not want ever changing map features in my car. Agile’s principal of “early and continuous delivery of valuable (navigation) software” would make me crazy and think it would be distracting.

Entertainment sources? Sure, change away. At a fundamental level, who really cares. But maps and navigation? That is absolutely core to my ability to use my vehicle.

It is not that I think Agile has no place in automotive. It is just there are other ways to develop products, even software products. The parts of Silicon Valley that want to play in automotive need to be open-minded to all the ways of developing products. And recognize that Agile is not the end all be all, even while being great.