[icebraining]

I don't disagree with the digs at Scrum and similar implementations of Agile, and I certainly agree with the spirit of criticizing (in the 'art critic' sense) the processes we use, instead of blindingly accepting whatever gets thrown at us.

That said, I think this post falls short at acknowledging the difference between the general Agile concept and Scrum as a particular implementation (of which there are many), and I have a few further disagreements:

Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories”

Translation: instead of working the way I enjoy working, programmers have to work in a way I dislike, therefore Agile is terrible.

As a programmer, I like working on small features and projects, and the variety that comes from taking on different types of work.

Long-term stuff is nice too, but despite what you might think, not everyone gets excited about the same things you do.

often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high).

People being disallowed to work on core improvements happens in any kind of organization system.

Around here, we use "processes [that] promote sustainable development" and which allow us to "maintain a constant pace indefinitely." That means occasionally allocating people to refactor and improve the codebase, when the programmers feel that need and point it out.

Atomized user stories aren’t good for engineers’ careers.

Well, then it shouldn't be hard to show that engineers with Agile-based work experience have more difficulty getting hired. Is there evidence on that?

5. Its purpose is to identify low performers, but it has an unacceptably false positive rate.

Absolutely no argument here. The constant tracking is demeaning and often counter-productive.

That said, I don't think Agile requires it, just specific implementations of it (like the aforementioned Scrum).

[spronkey]

Agreed with many of your points - although I don't think that the purpose is to identify low performers, per se.

It's more about breaking down development into small chunks at a time, so that if there are performance (or specification, or other) issues, they can be dealt with quickly.