Perhaps "complexity" should be used instead of "great engineering". The best engineered solutions are those that are simple, easy to understand, and fulfill business needs (profit, time to market, etc) vis-a-vis satisfying the programmer ego (In saying this, I'm pointing the finger back at myself as one who really loves to over-engineer)
That's how it usually works out though. I always get in trouble with management when I try to anticipate things we will probably need in 6 months before making design decisions.
A lot of people think that Scrum means not looking beyond the end of the next sprint.
They do not emphasize feedback and iteration over quality.