Scrum definitely focuses on "What", but it is much more than the author claims. The difference between Scrum and "old school engineering" (aka waterfall) is primarily that Scrum actually measures the full production cycle; you can't do that with the long development cycles of waterfall. If you use Scrum to measure the full development cycle (which means you actually ship the Sprint product), you can then use velocity to forecast feature delivery in the future with some statistical justification.
If your engineers say that "agile doesn't forecast", they are giving you a snow-job. They are using agile as a weapon against naive Product Managers who don't understand Scrum and why it was created. Scrum was designed to replace the inaccuracies of waterfall "pseudo forecasting", which had resulted in many projects failing dramatically. Basically, waterfall "planning" is hypothesis without any verification. In contrast, Scrum verifies with shipped product every Sprint.
Astute product managers can use Scrum's verified velocity to forecast far into the future, with the usual tools of statistics (such as standard deviation, etc.). It isn't prescient, but it's the best we have. Waterfall is far worse.
Scrum done well is an experimental framework for measuring and improving feature production. It works when done well, but it is hard to do.
You can think of Scrum as a religion, but only in the way that atheism/agnosticism is a "religion". There's faith-based development and that includes waterfall; there's reality-based development and that includes Scrum (but could include any other technique where you measure and forecast using shipped product and velocity).
On the matter of Product Management, Scrum's short iterations buy you something cool: You can do Lean Product Management a la Eric Ries. This is the Product converse of Development's Scrum. Lean Product Management says "We don't know that much about the market, so let's run experiments to find out more, then let's adapt as we learn."
Scrum lets you experiment with production; Lean Product lets you experiment with markets. If you are certain that your production methods are sufficient (and you don't need truthful forecasting), then you don't need the experimentation of Scrum. If you are certain your market hypotheses are right, then you don't need the experimentation of Lean Product.
I did a study of release duration at Citrix Online to see whether our adoption of Scrum and Enterprise Scrum (something we developed to manage project portfolios) was working. You can see it here: http://senexrex.com/wp-content/uploads/2013/02/Release-Durat...
It shows that agile reduced the shipping duration of projects from 24-42 months to around 4 months. During that time Citrix Online's market share increased.
It's going to be hard to get the side-by-side comparisons you seek, and, sure, it could be that the agile-focused management happened to also be competent (hey, I'll accept that. :)). However, I actually think Scrum specifically is a science that measures production, and that its outcomes are usually pretty good.
Since I've now helped convert a couple of huge enterprises to Scrum, and since I love tracking data about those conversions (and it's good), I make money in this field. So you could say I'm a flogger of the religion. At the same time, I have a computer science PhD and I could be out wrangling code or running a startup.
And you are right, there are a bunch of religious zealouts out there. They annoy me too.
If your engineers say that "agile doesn't forecast", they are giving you a snow-job. They are using agile as a weapon against naive Product Managers who don't understand Scrum and why it was created. Scrum was designed to replace the inaccuracies of waterfall "pseudo forecasting", which had resulted in many projects failing dramatically. Basically, waterfall "planning" is hypothesis without any verification. In contrast, Scrum verifies with shipped product every Sprint.
Astute product managers can use Scrum's verified velocity to forecast far into the future, with the usual tools of statistics (such as standard deviation, etc.). It isn't prescient, but it's the best we have. Waterfall is far worse.
Scrum done well is an experimental framework for measuring and improving feature production. It works when done well, but it is hard to do.
You can think of Scrum as a religion, but only in the way that atheism/agnosticism is a "religion". There's faith-based development and that includes waterfall; there's reality-based development and that includes Scrum (but could include any other technique where you measure and forecast using shipped product and velocity).
On the matter of Product Management, Scrum's short iterations buy you something cool: You can do Lean Product Management a la Eric Ries. This is the Product converse of Development's Scrum. Lean Product Management says "We don't know that much about the market, so let's run experiments to find out more, then let's adapt as we learn."
Scrum lets you experiment with production; Lean Product lets you experiment with markets. If you are certain that your production methods are sufficient (and you don't need truthful forecasting), then you don't need the experimentation of Scrum. If you are certain your market hypotheses are right, then you don't need the experimentation of Lean Product.