Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Is Tesla is using Scrum? Should they?

This site may earn commission on affiliate links.
I (as well as a few others on the forums) have in the past made comments that we suspected Tesla was using an Agile methodology to build the software in the Model S. This slide from a TEDx talk given by Jeff Sutherland seems to confirm this. Even more surprisingly, Dr. Sutherland makes a comment that someone is working on building a car using the Scrum methodology. He doesn't specifically say it is Tesla, but I wonder if that is who he is referring to.
 
Is Tesla Using Scrum?

In my recent TEDx talk I mentioned a car company building cars with Scrum and was referring to Wikispeed. They build opensource cars that get more than 100 miles per gallon using one week sprints. As for Tesla, we know there are Certified Scrum Masters working there. We know Toyota made an investment. We know that they are agile in updating both their software and the and car at regular intervals. (At least for my Model S. My Roadster does not get such treatment.) Unfortunately, their marketing people won't let us talk to engineers about how they work. However, Scrum derives from lean product development at Toyota where Taiichi Ohno used cross-functional teams and short iterations with continuous improvement. They clearly are doing something similar. Maybe someday their publicity people will not block all communication.

I (as well as a few others on the forums) have in the past made comments that we suspected Tesla was using an Agile methodology to build the software in the Model S. This slide from a TEDx talk given by Jeff Sutherland seems to confirm this. Even more surprisingly, Dr. Sutherland makes a comment that someone is working on building a car using the Scrum methodology. He doesn't specifically say it is Tesla, but I wonder if that is who he is referring to.
 
scrum is just an excuse for not documenting your code and rushing things to production before they are properly designed and thoroughly tested. this isn't surprising considering all the functional and non-functional (performance, reliability) bugs they have in their UI.
 
scrum is just an excuse for not documenting your code and rushing things to production before they are properly designed and thoroughly tested.

Waterfall is just a way for teams to "protect" themselves from doing what's needed to ship the best product possible, and to have excuses for not shipping on time.

Do we really want to rehash this battle here? Poorly done Scrum is better than poorly done Waterfall, because at least you know about the problems sooner.
 
scrum is just an excuse for not documenting your code and rushing things to production before they are properly designed and thoroughly tested. this isn't surprising considering all the functional and non-functional (performance, reliability) bugs they have in their UI.

Then it's not implemented correctly. Agile methodology is frequently mistaken as a shortcut. It actually requires more team discipline - and requires the same amount of work, but can shorten develop time and result in better end product IF done right.

But unfortunately there are a lot of people using words like scrum and Agile as excuses for shoddy work.

- - - Updated - - -

Do we really want to rehash this battle here? Poorly done Scrum is better than poorly done Waterfall, because at least you know about the problems sooner.

Yes! Let's rehash it!

If you have an undisciplined team, then you need a waterfall methodology. Because it's the only way to get a product development effort to a predictable end point in any usable shape. If the team is experienced and actually understands the importance of early activities, then scrum. But you don't get there overnight.
 
Then it's not implemented correctly. Agile methodology is frequently mistaken as a shortcut. It actually requires more team discipline - and requires the same amount of work, but can shorten develop time and result in better end product IF done right.

But unfortunately there are a lot of people using words like scrum and Agile as excuses for shoddy work.

agreed

If you have an undisciplined team, then you need a waterfall methodology. Because it's the only way to get a product development effort to a predictable end point in any usable shape. If the team is experienced and actually understands the importance of early activities, then scrum. But you don't get there overnight.

again, agreed!! I've seen far better products from groups using the waterfall approach than teams using the agile scrum approach. In fact, I've yet to personally come across a team in 12 years that was using the scrum methodology successfully who produced a reliable high quality product. instead they usually end up taking much longer than the waterfall approach because they produce huge amounts of untested spaghetti code that ends up such a mess that the engineers who coded it can't even figure out how to debug it. I've seen entire groups of engineers disbanded and reassigned or cut entirely (fired) because they couldn't produce anything good after months or years of development on products using agile approach. they also end up spending too much time in meetings which are supposed to be short but never are. one of the key principles is one of the biggest problems - requirements churn. they change their damn minds so often that code gets rehashed over and over and nothing meaningful ever produced or released.


obviously I'm not a fan of scrum. i've never seen it work successfully in a team dynamic.
 
agreed



again, agreed!! I've seen far better products from groups using the waterfall approach than teams using the agile scrum approach. In fact, I've yet to personally come across a team in 12 years that was using the scrum methodology successfully who produced a reliable high quality product. instead they usually end up taking much longer than the waterfall approach because they produce huge amounts of untested spaghetti code that ends up such a mess that the engineers who coded it can't even figure out how to debug it. I've seen entire groups of engineers disbanded and reassigned or cut entirely (fired) because they couldn't produce anything good after months or years of development on products using agile approach. they also end up spending too much time in meetings which are supposed to be short but never are. one of the key principles is one of the biggest problems - requirements churn. they change their damn minds so often that code gets rehashed over and over and nothing meaningful ever produced or released.


obviously I'm not a fan of scrum. i've never seen it work successfully in a team dynamic.


I've seen it work extremely well. And when it does, it's a thing of beauty. Can't be done better.

And I've seen it faceplant in spectacular ways. It really has come down to (imo) how well the team has bought into the importance of early foundational work. If they truly recognize the value, it's probably going to go well, But if it's just lip service, then they will come up with excuse after excuse. And I'll be left wishing I'd enforced a waterfall methodology that was heavy on early user studies, with plenty of time for updating requirements and specs built in.

- - - Updated - - -

And I have to admit I'm feeling a little *off* because we've agreed on something. -shake it off-
 
FWIW, waterfall as it's almost always used isn't what Winston Royce actually envisioned, something I wrote about here: Software History: Waterfall – The Process That Wasn’t Meant To Be | Online Business Systems.

I'm not necessarily a fan of agile, usually because of misuse, but a huge believer in iterative development which fits well with agile on disciplined teams. I think it was Barry Boehm that pushed to the Dept of Defense to finally accept iterative (he created the Spiral Model, if I recall), because of fairly strong evidence it was better than waterfall. Iterative development, of which agile is a branch, is not new, with Harlan Mills championing it as far back as the early 70s.

A quote (from the IEEE article http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf) where Winston reiterates that he really didn't intend for Waterfall to be used the way it has been. The quote is from Winston's son about his father:
He was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects.
 
Last edited:
Agile is good if your customers like to see new features quickly and are willing to live with rough edges with the understanding that they can tell you about them and get them fixed quickly.
Agile works best if everyone is on-board including the customers using the product. And the feedback loop has to be wide open through the whole process.
Scrum's are just part of the process to make sure things keep flowing quickly and things are broken down in to small enough tasks.
 
I nominate jeffsutherland for TMC lurker of the year. Join date Oct 2011, first post is written only 1 hour after someone mentions him by name!
Good to have you here as both a Model S and Roadster owner!

I second that.

And, let me say, thank you for giving us Scrum. I read everything you write and watch every talk and interview you give. Almost as bad as my Elon stalking habit. Working on a true Scrum team is indeed a life changing experience, glad I had that chance early on in my career.

Actually, I'm trying to find one right now if anyone knows of any good teams the Raleigh area. Can't go back to doing things the old way.
 
Agile is good if your customers like to see new features quickly and are willing to live with rough edges with the understanding that they can tell you about them and get them fixed quickly.
Agile works best if everyone is on-board including the customers using the product. And the feedback loop has to be wide open through the whole process.
Scrum's are just part of the process to make sure things keep flowing quickly and things are broken down in to small enough tasks.

There are tools/methodology you can use with customers to help them understand which features need to be locked down earlier than others (mostly showing relationships between features - if you change the UI, lots of impacts, but if you change the case color or texture, probably not so many). It's a way to leave customers with some perceived control 'we only need you to lock down these features early, you can leave these other ones til later, without impacting schedule or budget'. Get them focused on early studies and iterations necessary for fully understanding those particular features, and they can waffle all they want on the stuff that really has no material impact on the design activities. ... If you ever want to talk (have done this particular topic a lot for companies) just let me know.

- - - Updated - - -

In my recent TEDx talk I mentioned a car company building cars with Scrum and was referring to Wikispeed. They build opensource cars that get more than 100 miles per gallon using one week sprints. As for Tesla, we know there are Certified Scrum Masters working there. We know Toyota made an investment. We know that they are agile in updating both their software and the and car at regular intervals. (At least for my Model S. My Roadster does not get such treatment.) Unfortunately, their marketing people won't let us talk to engineers about how they work. However, Scrum derives from lean product development at Toyota where Taiichi Ohno used cross-functional teams and short iterations with continuous improvement. They clearly are doing something similar. Maybe someday their publicity people will not block all communication.

Huge welcome, Jeff. Any chance you know Dean Leffingwell? Dean's an old friend & work colleague from way back .. he's got a couple of stories about me in his Agile books :) (names have been removed to protect the innocent!). Surely the two of you have crossed paths a bit.
 
Agile is good if your customers like to see new features quickly and are willing to live with rough edges with the understanding that they can tell you about them and get them fixed quickly.
Agile works best if everyone is on-board including the customers using the product. And the feedback loop has to be wide open through the whole process.
Scrum's are just part of the process to make sure things keep flowing quickly and things are broken down in to small enough tasks.

Time-to-market is also about time-to-revenue, its gets revenue producing or market-differentiating features out the door sooner. Agile-at-scale is hard to do, but I'd bet on it over waterfall 9 out of 10 times.

Disclaimer: It am a Certified Product Owner
 
Time-to-market is also about time-to-revenue, its gets revenue producing or market-differentiating features out the door sooner. Agile-at-scale is hard to do, but I'd bet on it over waterfall 9 out of 10 times.

Disclaimer: It am a Certified Product Owner

Depends on the kind of product ... much trickier when it is something like a regulated medical device, where development documentation is both subject to inspection and also will likely be part of a product submission. You don't get to have rough edges or missing features. Agile can still be better than waterfall - just need an experienced team.
 
Depends on the kind of product ... much trickier when it is something like a regulated medical device, where development documentation is both subject to inspection and also will likely be part of a product submission. You don't get to have rough edges or missing features. Agile can still be better than waterfall - just need an experienced team.
Having worked in the medical industry (like bonnie), there's certainly a whole different level of process and documentation required, which can pose challenges for agile teams where communication is intended to remove the need for some documentation (that rapid customer feedback loop, rather than specs up front). You can capture some of that documentation work with stories/tasks where the FDA is the stakeholder and I'm sure there's lots of other techniques to make agile work in such an environment.

Beating the same drum I have before I suppose, but for me it's still about being iterative in that environment rather than waterfall, regardless of how agile (or not) the situation allows.
 
agreed



again, agreed!! I've seen far better products from groups using the waterfall approach than teams using the agile scrum approach. In fact, I've yet to personally come across a team in 12 years that was using the scrum methodology successfully who produced a reliable high quality product. instead they usually end up taking much longer than the waterfall approach because they produce huge amounts of untested spaghetti code that ends up such a mess that the engineers who coded it can't even figure out how to debug it. I've seen entire groups of engineers disbanded and reassigned or cut entirely (fired) because they couldn't produce anything good after months or years of development on products using agile approach. they also end up spending too much time in meetings which are supposed to be short but never are. one of the key principles is one of the biggest problems - requirements churn. they change their damn minds so often that code gets rehashed over and over and nothing meaningful ever produced or released.


obviously I'm not a fan of scrum. i've never seen it work successfully in a team dynamic.

What!! I just saw it work on the show Silicon Valley.

I don't think you are talking about Agile coding. In Agile coding there is supposed to be automated testing every night after you check in your files. If it's untested, you're not doing it correctly.

I've done the waterfall method for years and years, then did the Agile method for a year a little while ago. I like things from both of them, but I really like the automated testing that is done with Agile. Of course you could do it in the waterfall method, but you wouldn't be testing the complete "package". I also had a program that did the waterfall method with iterative releases, and I liked that one the best.
 
From my own personal experience I find the only people who like SCRUM are the upper managers who aren't being subjected to it. To them work is getting done faster. They don't care about the quality of the work only the quantity. Code is written to fulfill a requirement in the fastest way possible. No thought is given to coding standards and best practices leading to framework atrophy in the long term. I've seen projects fail just as often with SCRUM as they do with Waterfall. What really matters is good leadership. The best most creative developers in the world can be undermined by a few bad apples.