Mike’s got some great points about how agile goes wrong. I’ve seen them all.
The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team. The motivation and empowerment of programmers has a direct and strong relationship to the quality of the software. Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver. The consequences of poor design decisions multiply rapidly. It will usually take multiple attempts to arrive at a viable design. You should make it easy to throw away code and start again. Latency kills. Short feedback loops to measurable outcomes create good software. Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy. Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software. Coconut Headphones: Why Agile Has Failed
However, there are some reasons, in my experience, why developers contribute to this problem as much as non-developers. A lot of it comes down to the team quality bullet above, but…
Unless highly technical people step into the “project management” and “architecture” roles and develop the credibility with the technical teams AND the people paying for the work, we need to get to a place where predictability can be had while including nontechnical folks to “run the process”.
I think you misinterpret his entire post, the bullets he puts up is not why agile fails, the very opposite, the bullets in that list is what agile meant to value, but when people in charge don't understand what to value software will fail no matter what you call the process.
Being an architect is not a special discipline, it is when you define it as one you start the slippery slope of failure, architecture is part of software design, done by the team, not a separate entity.
The most difficult thing I see teams struggling with is "time."
For some reason, when you are wasting your internal developer's time...that time is "Free." Meetings balloon and multiply, emails pile up, sticky notes start covering walls...daily stand ups...test driven development...automation...pair programming...extreme programming etc etc etc. It never ends.
Take that same company and put them with a vendor who says "Well, we could do what you just asked but that will cost you $75,000 more than the budget.
100% of the time, that dumb thing or process which would make the project late and go way over budget gets dropped. That never happens on internal teams.
Internally, if you don't want to do something which is an obvious waste of time you are not a team player, you are lazy and get stack ranked at the bottom.
That is why Agile fails more than any other reason. Someone needs to be the "hey guys, this actually burns more money than it is worth and makes us late."
Niclas, his bullet points are examples of how agile flops when people do not understand why they're doing something and/or choose to do "the wrong thing" with agile. Neither of us are knocking agile, we're both huge fans. =)