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 am trying to reconcile these two statements made by the author:
1) "[Scrum] provides a framework that prioritizes delivering real, working, business-quality software sprint after sprint."
2) "Scrum is engineering centric. Great companies are customer and product centric."
So, with the second quote the author sets up this dichotomy between Scrum and being customer-focused. But to me, the first quote (which is accurate) positions Scrum as supremely customer-focused. Meaning, to deliver value as soon as possible, as much as possible.
I think the author fails to make any persuasive arguments about Scrum. His arguments about what Scrum is not are inaccurate. I was hoping for some useful counter-perspective.
I don't think that those two statements are inconsistent. The OP is not disparaging scrum, but rather pointing out that when organizations embrace scrum as a religion they lose sight of the fact that scrum is a tool for engineering - it is not the complete answer to making good products.
Scrum provides a tool that allows you to run your engineering org like a factory production line - it is efficient and (sometimes) predictable. But just having a good production line doesn't mean that you are going to build a product that customers want to buy - only that you will build something faster.
I agree that most of scrum is focused on engineering. The product owner is where it focus lies on product. I've seen companies where product managers became better in having product delivered on time when they adopted the Product Owner role with scrum teams.
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.