Cards Don't Build Software, People Build Software

I've been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I've seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.

So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.

From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it's assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?

Just because I'm Agile, doesn't mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision - If I don't write down or draw models of the software I need, I'm bound to forget. What tends to be lost on a lot of new Agile adopters is: It's okay to write things down, just don't try to write down absolutely everything before you start building.