The whole post seemed so wrong compared to my experience, I decided to compile a list of specific complaints he has on how Agile works.

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

These decisions are invariably made by business people who will call shots based on emotion rather than deep insight into the technical challenges or the nature of the development.

Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized “user stories” or two-week sprints.

Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it.

meaning that no one looks out five “sprints” ahead.

it eradicates even the possibility of work that’s acceptable for a mid-career or senior engineer.

“Agile” and Scrum glorify emergency. That’s the first problem with them. They’re a reinvention of what the video game industry calls “crunch time”. It’s not sustainable.

I actually think this is a useful list for anyone transitioning to agile development: these are all pitfalls that a certain kind of dysfunctional organization will try to twist it into. I even know that we actually had one or two of these problems in my organization, which took some time of engineering push-back to fix, and we narrowly avoided a few others.

I think the key element that the article is missing is that it blames Agile/Scrum for dysfunctional management, where in fact dysfunctional management will always produce dysfunctional organizations, with different flavors of dysfunction based on what it was trying to achieve.

For a counterpoint to many of the bad experiences offered up by the article, here are some good experiences you can expect to have if you adopt agile practices in a good, functional organization:

• empowered engineers, as a history of delivering working code at a regular cadence makes the business side trust their judgment in estimates, in missing a deadline here and there (since they can trust it will at wires be delivered in the next iteration), and even in proposing non-traditional solutions
• a culture of no compromises to quality and no half-done work, as the regular schedule can't be maintained in the presence of an unstable code base; automated testing of all kinds will flourish in a good agile shop
• a culture of practical designs and constant refactoring, as the tight focus encourages YAGNI practices as opposed to monumental designs, but YAGNI requires a "always leave things a little better than you found them" mentality if quality is to be maintained
• a culture of looking ahead to identify risky features and research areas many iterations ahead, since you can't maintain a constant pace if you don't have a good idea of how long everything takes, and start well ahead of time on the big rocks, in parallel with the smaller deliverables
• a constant pace of effort, with no crunch time (nor any slack time), as the constant pace of delivery, high standard of quality, and careful look-ahead, plus the flexible backlog model, leave little room for urgent requests, slipping deadlines or customer hot sites
• high value placed on experienced architects and developers, who are constantly challenged with creating flexible, simple designs that are easy to grow iteratively, delivering everything with high quality, and teaching the whole team how to balance the high focus on quality with the requirements of actually delivering

I am in no way claiming that these are universal, that if you simply follow the letter of the agile manifesto or scrum process right you will get here etc. - this is not 'no true Scotsman '. I'm simply saying that, while a bad organization doing agile (note: not 'an organization doing agile badly', but a bad organization doing agile as well as you want) will probably produce exactly the kinds of problems raised in the article, a good organization adopting the same practices should feel some if these advantages.

A good organization adopting some other kind of process or methodology or ideology will almost always produce good results, in different ways (for example, YAGNI is definitely not the only way of designing good software).