Why do some developers consider Agile development to be nonsense?

  IF teams are using Agile like that there doing it 
  wrong. It's meant to be recipe for collaborative, 
  relaxed, friendly environment.

I'm at a place where (IMHO) scrum works reasonably well. But some of the scrum language I hear people using kind of invites misunderstandings.

For example, "sprint" evokes runners running 100m at a pace they can't sustain for minutes, let alone weeks or months. And "committing to stories for this sprint" implies it's some sort of failure or emergency if the target is missed - when in truth nobody should be skimping on testing or staying late to get things done.

>Everyone seems to agree that we're doing Agile wrong

The fact that we've all heard this line (yet never heard a solution) should make it pretty clear that it's more of a management religion than an engineering practice. "You're doing it wrong" is the perfect built-in, pre-packaged defense to the Agile system that agile managers/consultants/etc can rattle off with zero effort and an air of superiority. Had a bad experience? Well, you were doing it wrong. It's not an issue with the system.

I recently worked at a place that was the text book example of agile/scrum development methodologies -- Which I don't mean figuratively, I mean in the literal sense, their big claim to fame was that they were the subject of a case study on the success of Agile methodologies. So, having worked in a place that was studied for "getting it right," it's extremely annoying to see all critiques of agile had waved away under the flag of "you did it wrong"

Just about every complaint in the article existed at this place as well. For me, at the tip top of the list was meetings. Planning would take hours. Sometimes it would be split up over two days. That is two days out of the 10 you have available for development eaten up by talking about what you're going to develop. Then there's a meeting to show what we did in those 10 days. Then another meeting to talk about what we think we did in those 10 days and how it could be better (which was of course done through stupid time wasting games ("I wish I could have ___" "I was happy when ___", "I should start doing ___"))

Then layer on top of all that a whole hierarchy of people whose whole job description is to be "agile" -- which not a single developer was able to explain to me the meaning since the day I started.

I'm ranting too much, but the whole agile thing just gets under my skin. It's such a massive waste of time. Leaving that company was a happy happy day. I now work at a place where 'planning' takes 15 minutes in front of a white board. Engineering discussions take as long as they need with the relevant parties whenever needed. Other than that, you're left alone to fucking do your job.

So instead of Agile we should use, what?

Fully understand that process is a technology.

If Agile is so bad, what's better?

Agile done wrong destroys more than Agile done right can fix.

If you feel too good, or too senior for a programming methodology like Agile, then you are bound to not like it. Is that a fault with Agile, or a fault with your attitude?

A cowboy coder is not micro-managed, does not seem to need atomized tasks, does not need a direct line with the customer and decides on the complexity of the problem and the solution all on his own. They are also terrible to manage and hit-and-miss when it comes to actually shipping something with business value.

Bluntly spoken, Agile is there for the project managers, not the project developers. Agile should be implemented for as long as productivity increases, customer feedback loops create desirable features, and iteration cycles become tighter and shorter. If you know a way to increase those stats without Agile, then write your own methodology (http://programming-motherfucker.com/ is taken) and join management. If you don't care about those stats, and feel too good/senior for Agile, then start your own company and proof it to yourself. You don't start to measure a project's success by first counting the number of developer complaints. You could probably keep the complaints at zero, and never ship anything of impact.

I don't know how the author is doing Agile, but it doesn't match my experience. I've implemented "Agile" processes on four different teams, and while certain aspects were more successful than others in different contexts, nothing was at all like what is described in the article.

For starters, a very significant part of the article relates to performance anxiety over story points. Over 6 years of doing this, I've had two instances where people were called out for not putting points on the board, both of which came from outside managers not familiar with Agile.

Besides that, one of the core tenets of Agile is that you adjust the processes to work for the people involved. Trying to enforce some arbitrary subset of Agile processes on a team is a recipe for failure and frustration.

This reads to me like "bad managers are bad at managing Agile processes".