The surprise of the Agile approach in continuous product improvement at Tesla
Once released into production, upon completion of industrialization activities, a new product enters a phase of development by small increments, which I refer to as “product maintenance.”
This phase involves the management of minor product enhancements to facilitate manufacturability, assembly, procurement
Small improvements are also motivated by the need to correct anomalies arising from the operation of the product in the field.
In my corporate experience in manufacturing companies, both mass-produced products and small-volume industrial machinery, this phase of product life is managed with lists of upgrades, ordered according to priority criteria.
Each intervention is normally managed with a PDCA cycle.
It is a phase of the product life cycle that I consider “complicated” because, in my opinion, the complex phase is the development of the entire product (Agile hardware development ), especially if it is very innovative and has a lot of unpredictability.
This management in PDCA mode, does not normally involve dedicated teams for each improvement action.
Interested people meet regularly to synchronize their work.
This is partial effectiveness management, because these are not micro projects with cross-functional teams with all the required skills.
No other management alternatives seemed possible until last week.
I attended the JoeDX workshop led by Joe Justice on Wednesday, November 9 and Thursday, November 10, during which Joe talked to us about how Tesla and SpaceX continue to update the product.
What has been most surprising to me is to see that these two companies do a product update, using the agile method, with such frequency that, technically, each car or element for the space may be different from the others.
This leads to an update rate unthinkable with traditional approaches.
This is a kind of Continuous Integration applied to serial physical products.
To do this Tesla is organized with thousands of small teams of 3 to 5 people who are responsible for a specific element of the machine.
Each of these teams proposes improvement actions on the machine subsystem or one of its components.
An AI application, based on millions of data collected from cars in the field, makes an impact assessment of each proposal and prioritizes development.
There are so many proposals that a human alone could not easily do this screening.
The whole thing then can be modified, if necessary, to human intervention.
These teams update the product by having all the necessary expertise in-house.
I will return later with more articles on how these skills are cultivated.
Each new alternative element that is developed can be installed on cars without modification due to the constraint of direct interchangeability or with the use of adapters.
It is impressive to see the integration between the teams’ work and data collection from the field, and their analysis with business intelligence systems.
This is accompanied by the support of Artificial Intelligence algorithms.
I wondered how much of this Agile approach is applicable to the Italian context.
I have also wondered whether the cost of all these adapters is always sustainable, because I have experienced their high cost in the industrial settings I know.
Thinking about continuous product improvement, with self-organized teams working iteratively and incrementally, is almost thought provoking.
A provocation because these are small projects without the complexity of systems of a product as a whole, to which Agile approaches are applied.
It is indeed true that approaches in the complex world can work in the complicated world but the reverse is not true.
