There are some valid criticisms here, though on balance I think the author enumerates costs without considering benefits. But the biggest complaint is a result

There are some valid criticisms here, though on balance I think the author enumerates costs without considering benefits. But the biggest complaint is a result of a common misconception: that scrum is somehow a replacement for software design. It is not, nor is it intended to be. The author seems to have a glimmer of understanding that this is the case: Scrum, however, is much closer to the problem solving approach, where analysis (breaking down a problem, and reassembling the solution) is the organizational tool. In order for an interpretive community to emerge, an organization needs ambiguity, open-ended conversations, and alternative perceptions. All of this, Scrum leaves to something else, whatever it is. But then goes on as though Scrum precludes any kind of thoughtful design or experimental innovation. Nonsense. Nothing in Scrum suggests that a team mindlessly go through sprint after sprint without ever pausing to have design sessions or build prototypes. And there is scant mention of the product owner at all; it's as though the author believes that software is designed by developers, for developers. Scrum is a way to implement a software design, flexibly and with the understanding that the design will change along the way. How you decide what to implement, how you arrive at that initial design, is up to you. If your organization doesn't understand how to create and manage the abstractions that make up a software application to begin with, then Scrum isn't going to save you.