Sorry about hurting your agile feelings!
Software engineers get to do "engineering" where they don't control their own deadlines, can be forced to launch at arbitrary unplanned times, where the customer can't explain what they want and what they want is always changing anyway, and they are effectively disempowered to fix any of this because they posess no debate-ending move like other forms of engineering do. And many other fundamental problems that make it a different kettle of fish altogether.
Take for instance a car company. The mechanical engineers designing camshafts won't have a scrum team, but the people working on engine software probably do.
SEs also work with civil engineers/site supervisors etc.
No there's no veto resides in hands of engineers in any industry. There's a reason why bridges collapse and buildings need to be tore down for safety. It's not because engineers got to decide what's right.
http://www.ejinsight.com/20180406-hk-engineers-raise-concern...
There are many more, but the fact that engineer's safety concerns were side stepped rarely sees light of the day after disaster strikes. Also it doesn't have to be a catastrophic failure. Sometimes the reduction of life span of a structure is cause of not taking care of all the concerns.
Also this does not stops with construction. Have you not heard about problems in cars or other engineering projects where safety concerns were ignored. If not, I have to ask you how old you are.
The second link has the same issue - the engineers cited as saying something is unsafe are saying that after problems are spotted and they are not the same people who built the bridge. Sure, anyone can say "that was clearly unsafe" after the fact.
To repeat, what I asked for is cases where the engineering management of a project said "this is not safe" at the time they were being told to build it and non-technical management then overruled them and put traffic on it anyway, that is, the engineers were not allowed to complete the job to their own level of safety satisfaction.
Please keep raising these questions so that those of us who don't believe in bizarre guru-based project management approaches can have a home in this industry.
It's as if our industry has this undercurrent of desire to reinvent the wheel instead of learning from what history is so good at teaching (providing context). No idea how on the mark I am about this.
Therefore, software engineers get a lot more attention in terms of how to increase efficiency. The difference is akin to why there’s so much work to get CEOs to be more efficient but not that much work to get janitors to be efficient. It’s not a value judgment. It’s just economical reality.
If your construction phase consists of "type 'make' and grab a coffee" and the most expensive part is the coffee, then any efficiencies you can find in the design process will make a big difference to your bottom line.
If your construction phase costs tens of millions of dollars, you'll want to invest in designing more efficient construction methods rather than worry about tweaking the design process.
The lack of natural structure in the work means communication and collaboration among the development team(s) is all that more important.