I'm just throwing these links up for my own reference as much as anything else.
This article seems to argue that Agile is failing in many places due to misapplied Scrum:
But because Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design. Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt. Two or three years later, I get a call--or one of my colleagues does. "Changes take too long and cost too much!" I hear. "Teach us about test-driven development, or pairing, or acceptance testing!" By that time, fixing the real problems requires paying back a lot of technical debt, and could take years.
...
There are a lot of teams right now failing with Agile. These teams are working in short cycles. The increased planning frequency has given them more control over their work and they're discovering and fixing some problems. They feel good, and they really are seeing more success than they were before.
But they aren't working in shared workspaces or emphasizing high-bandwidth communication. They're don't have on-site customers or work in cross-functional teams. They don't even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don't use good engineering practices.
These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
Bob Martin, on the other hand, appears to disagree.
Scrum is not the problem. Scrum never was the problem. Scrum never will be the problem. The problem, dear craftsmen, is our own laziness.
It makes no sense to blame Scrum for the fact that we don’t write tests and don’t keep our code clean. We can’t blame scrum for technical debt. Technical debt was around long before there was scrum, and it’ll be around long after. No it’s not scrum that’s to blame. The culprits remain the same as they ever were: us.
...
It’s also true that scrum leaves a lot to be desired when it comes to engineering practices. But it is neither the purpose of scrum nor of CSMs to make engineers out of us, or to instill the disciplines of craftsmanship within us. That’s our job!
I think Bob's right. You can do lousy design no matter the method. You can write 'unit tests' that test nothing but accessors, or at best contain one hard-coded standard test case for a particular method. You can even write these useless tests before you write your code. You can plan iteratively, but the reality of deadlines produces a pressure to cut corners.
Craftsmanship requires time. If you simply don't have the time, Scrum or not, you're either going to get a lousy and unsatisfying product with lots of features, or a solid yet unsatisfying product with few features.
Yay!
