Polestar Forum banner

Thinking of Buying a Polestar? Here's a Reality Check.

17K views 112 replies 46 participants last post by  Haulr  
believe it or not - releasing unfinished software appears to be part of the strategy these days. IOW - if the OEM waits until the software is ready they will miss the market. So, releasing it now - and fixing it later - is just where almost everybody seems to be these days.

My understanding is that this is based upon Chinese (automobile) philosophy. lol.
It's not based on any form of Chinese philosophy. It's the result of a fad that started in software and was then applied to hardware development that caught fire across multiple industries over the past 10-15 years. That fad was Agile project management (trade marked 😜 ).

The adoption of that fad cost Volvo millions of dollars, delayed the release of the EX90 (and P3) by over a year, and has left them dealing with the fallout ever since.

Agile was snake oil sold to senior leadership across loads of different industries who were looking for ways to speed up software and hardware production to gain an edge. I don't know of a single one that benefitted in the long term, or made a better product, because of it. Instead what you see is loads of half baked products that end up causing headaches for everyone who comes after.
 
I'm feeling the need to defend both the car and agile development...

Agile is a far superior development methodology to the old 'Requirements > Design > Build > Test' option which in today's fast moving environment just means that by the time you get requirements signed off the world has moved on and they are no longer valid. Or worse, you stick with the old requirements and by the time it's ready for production it's useless and you've wasted a ton of money for something that's long out of date. For those complaining of half baked products and technical debt - you didn't do it right. The point of agile is just to build something iteratively so you can get feedback as you go along, adjust your approach so when you get to the end it's much closer to what you need instead of what you thought you wanted at the beginning when you didn't know anything. If it's launched half baked I can guarantee you that it was not the dev team's fault, it was management.
Yes, that's the Agile Kool-Aid.

It's not that the fast moving world made the original method obsolete, it's that people cough*senior corporate leadership*cough were looking for a shortcut to that. Agile is a shortcut that never actually delivers anything, because it's always in development, always iterating....but without proper documentation, because that "wastes" time.

"The point of agile is just to build something iteratively so you can get feedback as you go along, adjust your approach so when you get to the end"

That's brochure level double speak for "half-baked". What in the hell is a half-baked product, if not a product that's built (software or hardware), delivered, and then....iterated based on end user feedback? And the end? There is no end, because it's an endless feedback loop.

There's absolutely a place for user feedback and iteration within product development and progression. But Agile threw the baby out with the bathwater in an attempt to cut out a key element of development.

There's a reason Agile has slowly fallen out of favor, and isn't the hot C-suite talking point it was just 5 years ago.
 
Agile doesn't mean you deliver something half baked but it might mean you don't try to deliver everything all at once.
Again, that's by definition "half-baked". You are not delivering a complete product. Whether that happens to be okay or not isn't what defines it as half-baked. APM is by design about speed, which I think we agree. And it's speed ahead of completeness and ahead of customer satisfaction because you put the testing and research portion onto the end user/customer and hope for the best, and if you fall flat you hope to iterate out of the hole you dug.

We've been building a light rail line here in Toronto that's 5 years late and way over budget. That's waterfall.
That's just old school poor management. Those rail networks you're talking about in Europe and Asia were built, in segments, long before APM existed. (TGV is a great example)

Since this topic is supposed to be about cars, what about agile for cars? In my mind that means you build the core features you can't live without, roll the car out and then keep adding features. What we got with the P3 feels more like waterfall
Gonna cut that sentence right there. Earlier, I said that the P3 was a case study on the failure of APM when expanded beyond simple software. I didn't say that flippantly. It's been well reported about the failure of APM within Volvo and some of the higher profile hirings and firings that resulted. The P3 and EX90 delays were directly related to APM. The slow rollout of functions and features? Also APM, in part because of the APM driven decision to go with the Xavier chipset for production speed...and then 'iterate' up to Orin later.


So now, after you read that, and see the absolute havoc that APM caused, your following comment seems supremely out of touch when virtually every post in this forum and on the EX90 forums is made up of people complaining about the net results of APM, which you're trying to sell as somehow a benefit.

Guaranteed that agile will always deliver better against user needs (not wants) and faster vs waterfall approaches. BTW, you talk about agile never delivering anything and always iterating. The first part of the sentence is completely false but the second is absolutely true. For most useful products there will always be a backlog. The difference between agile and waterfall is how you prioritize and get the most important things out the door. Slowly via waterfall or quickly via agile. I think I read somewhere that Google was pushing updates out every few minutes - that is definitely agile...