Agile is a Sham

This is fair.

Furthermore, I think it's best to consider Agile in its proper historical perspective. When it first emerged, its principles -- as you've enumerated from the manifesto -- were uncommon enough to be novel and insightful. In this context, the Agile philosophy was a legitimate reaction to the problems of its day. Whether or not it's been an effective remedy to those problems is a matter of hotly contested argument. But one is, perhaps, inclined to be more charitable to Agile when fixing it into historical place.

In principle, I don't think it's fair to call Agile -- the core, original theory -- a "sham." Rather, the "sham" is all the rigidity, trappings, and liturgy that have grown up around Agile since it reached its saturation point. At some point, Agile started to ossify into a shadow-image of everything it was intended to fix. But I think that failing reflects the nature of its practitioners more than it does the core philosophy.

Thinking is hard. It seems like the cycle is a) someone thinks b) people follow without thinking c) someone realizes that unthinkingly following some process doesn't work so they debunk the theory without thinking.

So the question you have to ask yourself before you participate in b) or c) is do you have any idea why or how agile is supposed to help?

No. Process is important; it's necessary. There are at least two prongs to this problem: one is you can't manage what you don't measure, and process gives you a way of tracking functionality implemented, defects, defects resolved, etc. There's nothing inherent to programming that gives your manager or your team any sort of knowledge about how far along you are, or just as importantly, when you will be done. You can hack all you like and -- even if your code is visible to all -- there's no way of guessing how far along you are, or if that needs-to-be-fixed-yesterday bug is close to resolution.

The other prong to this problem is you can't remember what you don't record. Well, you may have an eidetic memory, but unless the company generates deliverables besides code that explain what the code does or is supposed to do, a change in team X years down the line may mean the company forgets why Joe wrote the widget wrangler in the way that he did, and accordingly the widget wrangling module becomes an unmaintainable black box. Generating these deliverables is a part of the software process, whether Agile or otherwise.

And there will always be a process. This arises simply as a consequence of the fact that management needs to know how well you're doing, and if you're performing in a cost-effective manner, to many decimal places of precision. And if the process isn't agile, it could be something far less pleasant.

Agile Processes (big A) may sound scammy to you, like their proponents are trying to sell back to you shit you already know. But you only know that shit because you're a software developer. Management can't do what you do, and they're the target audience of Agile Processes like Scrum and XP. It gives them a ready-made Industry Best Practice that they can decide with confidence to adopt company-wide, with little perceived risk because it's so proven and widespread. Compare and contrast with the success of the "open source" meme in convincing companies to adopt, and participate in, free software.

Yeah, you nailed it. I have seen this done so poorly so many times that I simply tell people to rotate the ScrumMaster role. Otherwise they just make it into a manager.

A lot of times they want to keep the old Project Manager around, and that's very difficult to do. Project Managers and ScrumMasters are completely different animals. A few times as a coach I have literally thrown the PM out of the stand-ups and told them not to come back because they were turning it into a status meeting.

I'm not trying to plug coaching, but if you're trying Agile, you really need an independent outsider to help referee stuff like this. Maybe it's only the SM from the team down the hall, but stuff like broken standups can be impossible to fix without a little neutral nudging.

Relevant article: http://www.joelonsoftware.com/articles/fog0000000024.html

Of course, you need process if you really want to consistently create defect-free software: http://www.fastcompany.com/magazine/06/writestuff.html