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.
From my own personal experience I find the only people who like SCRUM are the upper managers who aren't being subjected to it.
My experience is exactly the opposite across about 6 companies. Upper management hates SCRUM because it doesn't define long term delivery deadlines and upper management and sales want a hard date multiple quarters or years in advance. Engineers typically like it because SCRUM (and things like it) defined iterative short term targets on to the way to the longer goal.
 
My experience is exactly the opposite across about 6 companies. Upper management hates SCRUM because it doesn't define long term delivery deadlines and upper management and sales want a hard date multiple quarters or years in advance. Engineers typically like it because SCRUM (and things like it) defined iterative short term targets on to the way to the longer goal.

I would have to concur. The most successful software projects I have been on have been run Agile (Scrum). And in my current role as a Scrummaster, I find that everyone (with the exception of finance) loves the flexibility, speed, and quality that comes from Agile.
 
So Lis G as someone who's job depends on SCRUM you therefor agree that SCRUM is best. Priceless.
And ckessel if upper management hated SCRUM, SCRUM would not exist at that company since they are the ones who set policy.
 
So Lis G as someone who's job depends on SCRUM you therefor agree that SCRUM is best. Priceless.
And ckessel if upper management hated SCRUM, SCRUM would not exist at that company since they are the ones who set policy.

Whoa. Harsh & not accurate in my experience.

The position of scrum master exists because the methodology has proven out to be successful. Not because someone is protecting their job.

And many in upper management would like to understand 'what exactly is going on in engineering'. Perhaps ckessel overstated with 'hates agile' but the simple fact is it is harder for non technical people to understand than a more traditional waterfall approach. Having been in upper management at some fairly large companies, I can tell you that not everyone at that level is in full agreement on anything - so some may hate something while others don't. And if those responsible for engineering activities are typically successful at meeting commitments, it doesn't matter how much everyone else in upper managment hates the approach they are taking. Results matter. End of story.

Settle.
 
I run a global development shop and rather than decide on agile, waterfall etc, its determined delivery is based on the project and business value it will bring. I would expect Tesla to be delivering their products utilizing different methods based on the value that particular product will deliver. Agile is usually a 2-4 week to production effort, I haven't witnessed any (not that I know them all) of their production deliveries in that timeframe so are they really using agile, or a hybrid?
 
I run a global development shop and rather than decide on agile, waterfall etc, its determined delivery is based on the project and business value it will bring. I would expect Tesla to be delivering their products utilizing different methods based on the value that particular product will deliver. Agile is usually a 2-4 week to production effort, I haven't witnessed any (not that I know them all) of their production deliveries in that timeframe so are they really using agile, or a hybrid?
^^^ This from someone with experience. Nice.
 
Bonnie have you ever worked on a SCRUM team? As a pig not as a chicken.

Hahaha. Oh my. No, I dropped from the sky and landed in upper management because that's how it works. As in ... oh I wish it worked that way.

So a little of my background, Mr. Condescending. Worked as a software engineer for a number of startups (including with a fellow forum member somewhere around here) with absolutely NO process in place. Slowly brought in both waterfall and agile methodologies, watched software projects start to snap into place ... but not the equivalent was happening with electrical, hardware, or any other discipline. So started working on bringing similar into place for those disciplines ... and guess what? Yeah. It works everywhere. Ended up moving into project management (leaving out all the all nighters and what not, but we all know about that stuff). And eventually took over on the medical device stuff because of understanding of process controls of all types - both waterfall methodology and agile approaches - and sometimes you just go off the reservation and make your own rules because you have to match the project and not some preconceived notion about what is right.

So sorry if that spoils your little 'have you ever worked on a team' put down. Because yeah, I have. Many times. And back in the day, we defined pig-dog duty. Something you might not yet have run into. Avoid it if you can. :)
 
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.

I have first hand knowledge of one of the biggest healthcare devices companies in the world doing exactly this kind of work via Agile. My team builds Agile development and testing tools, and they are one of our biggest customers. They need more help from the tools (can't do everything on notecards in that world) but that industry isn't anything Scrum can't handle. Like Jeff said earlier, Scrum came from Lean, which was developed by Toyota. Building cars is a heavily regulated industry too

Hell, since we've got Jeff Sutherland here, we could just ask him about PatientKeeper. He turned that company into one of the highest performing development organizations of all time. That was healthcare.
 
I have first hand knowledge of one of the biggest healthcare devices companies in the world doing exactly this kind of work via Agile. My team builds Agile development and testing tools, and they are one of our biggest customers. They need more help from the tools (can't do everything on notecards in that world) but that industry isn't anything Scrum can't handle. Like Jeff said earlier, Scrum came from Lean, which was developed by Toyota. Building cars is a heavily regulated industry too

Hell, since we've got Jeff Sutherland here, we could just ask him about PatientKeeper. He turned that company into one of the highest performing development organizations of all time. That was healthcare.

Hey, didn't say you couldn't! Was only replying to a poster saying you could go out with rough edges and such. Can't do that with a regulated device. Have done plenty of Agile-based development in the medical device arena, though probably more common to have a modified waterfall approach, with agile-like iterative steps within. As has been stated by others previously, depends on the product. If it was a well-defined next-gen, probably didn't need all the flexibility that an agile-based approach would bring.

The issue is that when you have a regulatory filing in the mix, such as a 510(k) or PMA, it's essentially a contract with the FDA (or whatever government you're working with) - you're saying you'll have these features and no more or no less - and the documentation and test data to prove it. Their clearance/approval is on that. So you don't get to modify it later without going back and redoing the submission, which is a major setback to the program.

(Healthcare is not the same as regulated medical devices ... PatientKeeper is a workflow app & not regulated by FDA. It is used by clinicians, yes. It is not regulated and doesn't have the same oversight. Totally diff animal.)
 
Last edited:
And just to put this myth about documentation and testing to bed, here's an example of a CMMI Level 5 company using Scrum (also coached by Dr. Sutherland).

And a Dilbert comic:

Dilbert comic strip for 11/26/2007 from the official Dilbert comic strips archive.

- - - Updated - - -

Hey, didn't say you couldn't! Was only replying to a poster saying you could go out with rough edges and such. Can't do that with a regulated device. Have done plenty of Agile-based development in the medical device arena, though probably more common to have a modified waterfall approach, with agile-like iterative steps within. As has been stated by others previously, depends on the product. If it was a well-defined next-gen, probably didn't need all the flexibility that an agile-based approach would bring.

The issue is that when you have a regulatory filing in the mix, such as a 510(k) or PMA, it's essentially a contract with the FDA (or whatever government you're working with) - you're saying you'll have these features and no more or no less - and the documentation and test data to prove it. Their clearance/approval is on that. So you don't get to modify it later without going back and redoing the submission, which is a major setback to the program.

I hear you, not trying to argue with you. Trying to say that I know for a fact that it is being done, it might even be common.
 
Trying to say that I know for a fact that it is being done, it might even be common.

It is common, at least from my recent experience. It will always depend on the type of product. A lower risk (defining as risk to user, not project) medical device with high user touch will be more suitable to Agile. But at the other end of the spectrum, something like an implantable, for instance, I'd probably argue a waterfall methodology. If there are unknowns, we can plan those studies into the project plan. Depends on the product, the technology, the use case, etc.
 
Agile is usually a 2-4 week to production effort, I haven't witnessed any (not that I know them all) of their production deliveries in that timeframe so are they really using agile, or a hybrid?
Agile doesn't ship things every 2-4 weeks. People have the most bizarre conceptions of what agile is.

There are iterations, typically focused on small set of features. The goal is typically to be 100% done with those features. Scrum, in particular, typically has the goal of bringing those features to shippable levels of usability and quality. This does not mean you will ship at that point! The ideal is that you could, at the end of any iteration, choose to ship what you've got because what's done so far is at a customer usable level, but the reality is you won't because it's not a viable product as a whole.

This is really not terribly different from heavier weight iterative methodologies introduced 30 or 40 years ago (agile isn't really new anymore either, being 15+ years old). The point is iterations focus work to completion on areas of functionality. Waterfall was a mile wide, inch deep at each stage: all requirements, then all design, etc, with nothing working until the end (which is actually a bastardized, crippled version of what Winston Royce actually advocated...see my earlier post).

Iterative tends to focus on the opposite approach, creating a very small set of working features, then moving on. Doing so uncovers a lot of risks in the first couple iterations: performance issues, hairy design problems, tricky network setups, etc. That's the big goal, finding out those nasty items up front whereas with waterfall you rarely find those out until the "big-bang" integration at the end.

It's also worth stating that agile really does not mean "coding faster". I've heard that so many times: "With agile, we'll get things done so much faster!". God no, that's not why iterative methodologies came about. The point is early insight into risks and early feedback on the items completed each iteration. Because of those things, you might very well end up being done sooner because you caught bad stuff early (either design problems or requirements problems), but you're not writing code any faster.

Nothing is going to take a 12 month project and magically make it 6 months. As Brooks said nearly 40 years ago, there is no silver bullet.
 
Agile doesn't ship things every 2-4 weeks. People have the most bizarre conceptions of what agile is.

There are iterations, typically focused on small set of features. The goal is typically to be 100% done with those features. Scrum, in particular, typically has the goal of bringing those features to shippable levels of usability and quality. This does not mean you will ship at that point! The ideal is that you could, at the end of any iteration, choose to ship what you've got because what's done so far is at a customer usable level, but the reality is you won't because it's not a viable product as a whole.

This is really not terribly different from heavier weight iterative methodologies introduced 30 or 40 years ago (agile isn't really new anymore either, being 15+ years old). The point is iterations focus work to completion on areas of functionality. Waterfall was a mile wide, inch deep at each stage: all requirements, then all design, etc, with nothing working until the end (which is actually a bastardized, crippled version of what Winston Royce actually advocated...see my earlier post).

Iterative tends to focus on the opposite approach, creating a very small set of working features, then moving on. Doing so uncovers a lot of risks in the first couple iterations: performance issues, hairy design problems, tricky network setups, etc. That's the big goal, finding out those nasty items up front whereas with waterfall you rarely find those out until the "big-bang" integration at the end.

It's also worth stating that agile really does not mean "coding faster". I've heard that so many times: "With agile, we'll get things done so much faster!". God no, that's not why iterative methodologies came about. The point is early insight into risks and early feedback on the items completed each iteration. Because of those things, you might very well end up being done sooner because you caught bad stuff early (either design problems or requirements problems), but you're not writing code any faster.

Nothing is going to take a 12 month project and magically make it 6 months. As Brooks said nearly 40 years ago, there is no silver bullet.

YES! Very well said, ck.
 
Agile doesn't ship things every 2-4 weeks. People have the most bizarre conceptions of what agile is.

There are iterations, typically focused on small set of features. The goal is typically to be 100% done with those features. Scrum, in particular, typically has the goal of bringing those features to shippable levels of usability and quality. This does not mean you will ship at that point! The ideal is that you could, at the end of any iteration, choose to ship what you've got because what's done so far is at a customer usable level, but the reality is you won't because it's not a viable product as a whole.

I don't fully agree with this as it depends on what you are producing. For example, I have a multitude of phone apps that Do go to production approx. every 4 weeks. As I said previously, it's all about the business value that a release will bring which will determine the release schedule.
 
I don't fully agree with this as it depends on what you are producing. For example, I have a multitude of phone apps that Do go to production approx. every 4 weeks. As I said previously, it's all about the business value that a release will bring which will determine the release schedule.

Waterfall methodology would also send it to production every four weeks, too, if you have feature sets that are suitable for release every four weeks. At least if done in an efficient manner. But that's the point. It's not the methodology, it's the application and the experience of the team. Pick the best methodology for what you're doing. New tech, lots of unknowns, heavy user interface ... Agile is the likely outcome. It's not about speed.
 
I don't fully agree with this as it depends on what you are producing.
I'm not sure what you're not agreeing with. Scrum gives you the chance to ship every few weeks, just like you said. Many places don't have a business model that supports it, but the option is there (in theory).

Some places take it to a continuous delivery model where it ships almost all the time. Some web tools work that way, almost invisibly to the user unless it's a major feature.