> It's not acceptable in others (i.e. you cannot just try things and see if they stick).
Why not?
> So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront, and this leads to higher failure rates, this is still an issue
That is an incorrect characterization of Agile. Maybe some "agile" companies use it as an excuse to avoid requirements, but that is definitely not part of the process.
If you fulfill the role of a supplier of a component in a bigger product (especially in an industrial setting), you cannot "try to build something".
People are not happy if you tell them that you want to iterate on their control system and deliver incremental value, or tell them that it's not possible in the contractually agreed way.
> That is an incorrect characterization of Agile.
These are also the cases where you just have to work out overarching requirements upfront.
Ah, fair. This is a startup site so my mind was on organization that have the freedom to pivot.
It is supposed to be that new requirements come from the customer though, working closely in conjunction with engineering team reps. So it’s more like “deliver MVP control system software, test it out with actual users, then incorporate their requested changes into the next sprint.”
I’m not surprised if most so-called agile teams didn’t do that though.
Yes, that's possible for product development in a startup (even necessary, because you don't know what you need to build), and in web dev, end user facing apps,...
For many other domains, the full incremental / Agile loop is not possible, and becomes disaster if it results in skipping upfront planning:
The counterparts you need to integrate with are often not done yet. Maybe the hardware is not finalized. The end user is years away. Maybe each test run is hugely expensive.
There is no MVP here, as in the system works as expected or it doesn't.
You cannot meaningfully iterate the core software running an MRI machine, a surgical system, financial clearing, pick-and-place machines, automatic rail protection, etc. towards correctness with the end user.
My startup is a hardware company where we are our own customer. You absolutely can iterate these kinds of projects instead of top-down waterfall planning based development. It just requires dog-fooding the product and using mockups or simulations for parts that haven’t been implemented yet.
Why not?
> So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront, and this leads to higher failure rates, this is still an issue
That is an incorrect characterization of Agile. Maybe some "agile" companies use it as an excuse to avoid requirements, but that is definitely not part of the process.