I'm not sure I understand the nuance you are trying to bring up. In a typical Agile shop, one would expect each module to be written or developed based on the module's requirements, and in the timeline agreed upon by the requisite parties. So if you honor the idea that each story must follow the INVEST paradigm (see below), then your question is really about building interdependent stories by different teams?
The only part of your scenario I have no experience with is building hardware devices. I have not been part of building custom hardware or physical devices, so I cannot speak to that - but would expect the R&D and manufacturing of prototypes would follow similar patterns.
When we build software, we strive to create loosely coupled services which depend on each other. This is one of the core tenants of writing cloud native software. That ensures each module is referenced through a safe interface, and can be turned off / on as needed based on some logic or control. To that extent, upgrading or replacing such a module is not very disruptive, so each module would have its own lifecycle. You can also achieve a similar flexibility with a plugin model for the things you are writing . Ideally, a plugin would be able to be turned on/off and have its own lifecycle outside of the core product you are building.
(
New to agile? INVEST in good user stories - Agile For All
| Agile For All |
remove preview |
 |
| New to agile? INVEST in good user stories - Agile For All |
| As a I want so that . Above is a very simple user story template. How can something so simple be so hard to get right? User stories make up the heart of agile development. They are the primary input to the team. |
| View this on Agile For All > |
|
|
)
------------------------------
David Greenstein
------------------------------