For tight hardware integration, iteration on design isn't appropriate because the hardware design was locked in to begin manufacturing.
Quite often software life cycles miss the hardware rapid prototyping phase and so there's a desynchronisation of iterative design.
Within the framework of the hardware, yes you can iterate on the specific implementation but the contract with the external hardware and the timeliness to deliver was fixed.
Agile struggles without agile being applied end-to-end, and so you get agile/waterfall mixes.
In my experience, they can still work. In my case we have annually field deployed (and difficult to update) firmware. Firmware feature additions and changes are an up-front known quantity (even if they turn out to be insufficient for the in theater usage). We can't change them. That's the root where any agile approach reaches an external impact limit.
Our little bubble is agile in a waterfall world.
However, where I am, there is a huge emphasis on "getting shit done" well ahead of schedule. I'm lucky to work with smart and motivated folks who together, work well and we are wildly successful.
My biggest gripe, shared among many of my coworkers, is the level of micromanagement. Multiple business analysts, product owners, stakeholders, SCRUM masters, managers, etc. who all share essentially the same job - delegating and scheduling work. It makes every project 10x more difficult and complex than it otherwise should be.
An example just from this past week: Project A: we are delivering a single product. Three managers, two SCRUM masters, multiple business analysts. We engineers have four different JIRA/task-boards to keep up with. All of them overlap, three of them are essentially the same board in different spaces. Each day we have 2-4 hours worth of meetings spread across stakeholders amongst those three boards where we regurgitate the exact same information.
It's repetitive, backward, and a time-waste. Some engineers are currently "revolting" by saying what I'm saying now - in the meetings themselves. We've had multiple blowups with management.
Having meetings and discussions spread so wide leads to a lot of confusion because us engineers appear to be the only conduit with which the analysts and managers are communicating. Often times, the different stakeholders will ask for the same features in different meetings, other times they ask for different or conflicting features which leads to confusion and the need to schedule more meetings to clarify as they are not communicating amongst each other.