If you have most of those prerequisites -- everyone agrees on a process, you have a good architecture, and the project staff are highly motivated and get along -- then basically any process will work. If you say that scrum only works when you have those, it does not speak well of scrum. The purpose of real engineering processes are to manage projects where not everyone sees eye to eye, you have a variety of per-worker productivity levels, and you probably have uncertainty about what you need or what is possible.
Every halfway-decent development methodology makes a big deal about breaking things down so they can be accurately estimated. If you look at the SEI's Personal/Team Software Processes (PSP/TSP), which are basically the waterfall method on steroids, one of the biggest objectives near the start of the project is to try to break tasks down into chunks no bigger than a day.
Obviously, when you break things down that much, you will be wrong a lot, but once you get a few projects under your belt, you should be pretty close for work that is similar to things you have done before -- and your estimates should be pessimistic about as often as they are optimistic, so the large number of smallish individual estimates averages out to a not-so-bad overall schedule error. (Another benefit is that when your work units are that small, you should have a pretty good estimate of project progress.)
AMD's CPU architecture has a similar purpose as hyperthreading -- to share hardware resources between what looks to the OS like independent cores -- but the tradeoff is different. Intel's hyperthreading approach only works to cover memory latency, because the hyperthreads share so many physical resources (I think basically everything except register files and hyperthreading-related state). AMD's is somewhat different in that each "module" has two independent integer ALUs, register files, and L1 data caches. The module has one L1 instruction cache, one L2 data cache, one FPU, and one instruction fetch/decode unit.
But AMD has always been pretty up-front about this architecture. There is maybe a cause of action against resellers who package the AMD chips into systems and do gloss over which aspects each "core" shares with another core, but AMD publicly presented the core-vs-module distinction well before the chips were released.
I've done software engineering in the past. It was slow and expensive, parts of it were tedious, and parts -- particularly fallout from the fact that (fairly) rigorous software engineering is rarely done -- involved more hassle than they should have been. Even at that job, most of what I did was more traditional software development than engineering, and all my other software-developing jobs have been far from the level of rigor and care that I would call engineering.
However, when I did software engineering, with clearly defined requirements and interfaces, with an explicit architecture and functional decomposition of the software, with carefully planned and executed verification and validation, the results were definitely higher quality than you would get from less time- and labor-intensive methods. Most of the time, cheaper methods are acceptable and worth the increased chance of defects. Flight systems, healthcare, other safety-critical systems, and financial computing usually, and justifiably, prefer to pay for more rigor and higher quality.
We're living in a golden age. All you need is gold. -- D.W. Robertson.