A lot of software (that's often written about) can be tested 'in production' with fairly minor consequences in the event of 'failures'. That's an obvious difference between developing or maintaining software versus something like airplanes.
But testing or validating the changes made in short iterations is important regardless. Agile stresses the utility of short iterations precisely so the changes in each iteration can be tested and validated ASAP. Whereas in a waterfall methodology, a larger set of changes, i.e. changes that would in agile be split among a number of iterations, is tested or validated together. And the more changes that end up being tested together, the larger the risk is that those changes, and more of them, will need to be scrapped or redone.
The problem with the "MAX" changes of the 737 MAX seems more due to those changes not being tested or validated with the relevant users, i.e. pilots, at all before being 'released'.
Yes, the flawed (or incorrect) reasoning was that the changes were relatively minor and thus didn't warrant the regulatory requirements for 'significant' changes. But that doesn't seem to have anything to do with how the changes were developed, whether their methodology was agile or waterfall (or anywhere in between).
Obviously you're more likely 'to have a bad time' if you don't respond to, let alone seek, feedback from users about the changes you're making.