/e: also I'm very interested in what your specific "anything else" would be.
It does nothing to solve fundamental issues inherently. But these fundamental issues are well known, so any method not addressing them is rather weak by default.
I know "but that's not agile" is a tired meme at this point, but if you read something like for instance the pattern work by guys like Jim Coplien and Sutherland [1], then Scrum as outlined by these communities of practices sounds pretty sensible. Just some random excerpts:
> Use Small Teams of people working on serialized work rather than striving for false parallelism.
> The Development Team organizes itself to get its work Done. The Development Team is solely responsible for how it does its work.
> Explicitly allot time for interrupts and do not allow more work than fits within the allotment.
> Create ad-hoc “birds of a feather” groups for each area of significant enterprise core competency or developer interest, where interested parties can trade notes on technologies, domain knowledge, and processes that are key to enterprise advancement.
etc.