My experience with Scrum is that it has a tendency, especially if implemented "textbook" with absolutely no flexibility, to completely de-emphasize any kind of architecture, forward thought, elegance, or big-picture thinking about the code.
The result tends to be a giant snotball of hacks. In my personal experience the biggest casualty is efficiency, followed by maintainability and scalability.
The fact is that good programmers write good code, and bad programmers write bad code. There is no management "methodology" that can make bad programmers write good code. There are, however, methodologies that make good programmers write bad code. Scrum at least can be one of these.
The textbook way of running Scrum is to have a retrospective at the end of every sprint where you find faults with the process and tunes it for your specific environment. If you skip over that part or worse, refuse to adjust the Scrum process because it breaks some rules, then You're Doing It Wrong.
If a methodology is so simple that it only requires you to do a few things and you're not doing those, than "you're doing it wrong" is not an excuse, it's an objective fact.
Besides that, given that Scrum is such a lightweight methodology, it's pretty hard to fail for competent programmers to fail using Scrum. Worst that can happen is that they find Scrum isn't an improvement over whatever they were doing before, which is cool. There's no one size fits all.
But failure is usually caused by other factors. The standard excuse for failing projects is of course blaming the methodology... Ever notice that in places where Scrum "fails" that is usually not exactly the first failure?
I disagree, Scrum's whole design and methodology (simple though it may be) contains serious flaws. Things like iterations (are we releasing iterations or features here?), as well as the poorly defined responsibilities of positions like the product owner and scrum master. Also it fails to adequately define how teams should confront the problems found in retrospective. Overall it often leads to a stuck process for the many, many teams that struggle with Scrum, and blaming everyone else for "doing it wrong" seems like a defensive cop out.
Scrum is to the product management process as management games like "colors" are to office team building and group psychology. Overly simplistic to the point of being nearly meaningless. By itself I find it provides very little real-world guidance for how teams should improve themselves and their process at all.
Thoughtful Edit: Don't get me wrong, I think Scrum has an initial value, but it is "meatless" for want of a better term. Anyone who really wants to improve a process for a dysfunctional team dynamic is going to need more than just some iterations and stories. Scrum is a starting point, but more often than not I think it is little more than that. Blame the team if you want, but I'll put at least some of the blame with the methodology not providing enough long term guidance.
I don't think it's reasonable to expect the process to define how a team should confront the problems found in a retrospective. Those project and team specific problems are likely to be unique and giving the team the framework to choose the best course of action is likely to more effective than some prescriptive process that says "If A then do B".
It also wasn't meant to provide guidance on how teams should improve themselves, that's up to the team to choose the best route to get there. It excels at enabling the team to make those decisions for themselves.
Well, either people are doing Scrum right, and it isn't working, or they are trying to do Scrum but failing. Which is it?
Is it the case that no matter what situation is presented, a Scrum zealot can always find a reason to say "Ah, you're not doing it right". That is to say that Scrum is so wishy-washy that there's always a get-out clause.
Or is it that in nearly all cases presented, there are key things which Scrum says to do that are not being done? That is to say, Scrum is pretty concrete about what needs to happen, and yet most cases presented are not doing these basic things.
The article presented in this discussion starts out by immediately saying that his ignores one of the basic rules of scrum (that a sprint's stories cannot be changed once started). The author appears to have decided that "this is Ok" because he then goes on to criticize Scrum.
So, in the example presented, I feel absolutely happy saying "You're doing it wrong".
Would you return a car because it doesn't start, even though you fail to exercise step 1 in the manual stating "Insert Key"?
What is really fucking tiring is that for some reason, a whole ream of programmers feel that they can decide for themselves that putting the key in the ignition is a waste of fucking time, and then loudly blame the car for not working, and further, anyone who has the temerity to say "put the fucking key in the ignition" is just some fucking whiner making excuses and saying "You're doing it wrong".
Yes, you are fucking doing it wrong. Feel free to not do it right. Just don't fucking complain that the car isn't getting you to where you need to be.
Scrum doesn't de-emphasize those things, bad programmers do.
I'm just following your logic here, which I agree with up to the point where Scrum has a negative influence.
I don't see how Scrum can encourage good programmers to write bad code, since it gives them all the room they need to write good code, and lets them decide how much time and effort they put into architecture etcetera.
Bad programmers however tend to get exposed by Scrum, since without anybody telling them they have to consider architecture, they will produce said giant snotball of hacks.
Scrum favors incremental/additive changes, which leads to inconsistencies. Often inconsistencies are too large to simply fit with some other task, and a separate task just for reconciling everything never gets prioritized. Viola.
I think this previous comment by michaelfeathers supports what you're saying:
"The fact of the matter is that too many people think that projects can be run through the interface of stories and feature lists without paying attention to the quality of the software underneath. And, when you don't pay attention to it, it suffers. This, really, is _Joel's Law of Leaky Abstractions_ applied to process. Business wants to see features, and if that abstraction is their only view of the project, they will be blindsided by creeping quality issues. It's nearly inevitable."
Quality issues aren't always architectural issues, but architectural issues (especially lack of any planned architecture) always cause major quality issues.
There are number of classic failure modes for Scrum. One of them is to not have a Product Backlog at all, or to only plan it out a few weeks.
Since you claim that in your experience, Scrum de-emphasizes forward thought and big-picture thinking, I can only conclude that you don't do this, and have decided to blame Scrum for this fact.
I suggest that you identify whatever it is that is preventing your team from creating a full product backlog.
The result tends to be a giant snotball of hacks. In my personal experience the biggest casualty is efficiency, followed by maintainability and scalability.
The fact is that good programmers write good code, and bad programmers write bad code. There is no management "methodology" that can make bad programmers write good code. There are, however, methodologies that make good programmers write bad code. Scrum at least can be one of these.