That approach works well if you're selling many, many copies of your software, or if the customer representative is intimately familiar with the customer's actual needs. For most more specialized development efforts, having a customer representative ends up adding a middleman, confusion and extra work.

What is the difference to actual development between "we have a launchable product after each sprint" versus "we launch our product after each sprint"? There are obvious differences to the users, but what makes the former superior to the latter when it comes to meeting the overall project goals?

Also, there are a lot of non-agile alternatives, many of which do (or can) incorporate periodic release-candidate checkpoints. It is simply not accurate to talk about "the" non-agile alternative.

While no process will reliably produce good software with a dysfunctional team, Agile seems to be much more sensitive to dysfunction than many other processes. If you have a team full of disciplined, skillful individuals led with integrity by focused managers, many well-documented software processes will let you deliver good software on schedule. In the real world, teams often fall short of that ideal, so it is important for a development method to be somewhat robust to imperfect use, but Agile seems to encourage frequent distractions and excessive back-and-forth.

Funnily enough, most (academic) software engineering researchers understand that "waterfall" was originally intended as an exaggerated -- strawman -- description of a methodology that nobody uses in practice. Most practitioners also understand that any non-trivial project involves some backtracking, and most involve some iteration on parts of the development lifecycle, and thus don't try to use a strict waterfall method. Most Agilistas didn't get either memo.

Your outline of running a software project applies equally well to a spiral method or a CMMI-compliant method or a lot of ad hoc methods without using any defined process. The practical problems with Agile are in the details that you glossed over that distinguish Agile from those alternative methods. Those other methods are not always better than Agile, but Agile is not always better -- and is frequently worse -- than them.

One of the hardest things for process designers to do is to fit their processes to the people who will use them.

Most hard-core proponents of Agile don't understand this. This shows up in the small number of places that do stand-up meetings right, that do automated *and* thorough testing right, that elicit useful input and direction from the customer, and so forth. Once you throw all the Agile processes together, few places can do most of it right, and that's one of the biggest reasons that Agile ends up being a poor fit so often.

When projects inevitably fail in those circumstances, it is just annoying human behavior that makes the Agilistas claim the failure is due to not doing Agile hard enough rather than doing Agile in the first place, and that's one of the biggest reasons that Agilistas end up being obnoxious blowhards so often.

Agile dictates that you have practically continuous customer input to the development process. How do you propose to get that -- and to communicate your expectations about those interactions with the customer -- without telling them about the methodology?

Journals and conferences don't want to publish negative results, so you very seldom hear about all the people who try a process and find that it sucks for them.

Process success stories in the software field have always been driven more by special circumstances than science. Nobody has yet figured out how to (or at least bothered to) control for variations in sample-group productivity well enough to generate reproducible results for most process changes, and all the practitioners want to optimize their processes for different things. For example, CMMI and its ancestors are good if you have a load of time, good requirements control, and a few good leaders mixed with a bunch of more ordinary workers; Agile is good if your customers value whims over checking all the boxes and having really robust software; etc.

Finally, software changes can have chaotic effects, which makes it hard to apply a lot of the control, prediction and robustness methods used in other engineering fields. This makes me think that there will always be a large element of individual skill and domain expertise in building and delivering successful software, and that processes will always need to be carefully chosen based on the team and the project.

If you're not doing Xtreme Agile, you're not doing Agile right.

Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.

You don't even have to get that far, you just have to minimally comprehend the bit that the blurb quotes from the article: "Emissions from drilling, including fracking, and leaks from transmission pipes totaled 225 million metric tons of carbon-dioxide equivalents during 2011, second only to power plants".

Contracts signed under duress are often void, as are contracts with unconscionable terms.

Were Aaron Greene and Morgan Gliedman arrested recently for legitimate dissent? Or were they arrested for illegally possessing destructive devices (and apparently planning to use them against others)? Also, don't you find it ironic that OWS is so heavily staffed by children of privilege like those two?

So your argument is that "cost of physically performing" really means the same thing as "cost of performing", and that the FSF included the word "physically" for no reason? Somehow I'm not terribly convinced.

Labor costs would generally be reasonable, but the license apparently bars rolling those in. If you don't like that, take it up with the FSF.

He was already in violation; he did not include either the source code or a written offer to provide source code with his binary version. If the binary version was accompanied by the source code, that would have ended his obligations; if it was accompanied by a written offer to provide source code, that would allow anyone to ask for the source code.

You obviously either never read the GPL or misunderstood it. It does not require one to possess a binary copy as a prerequisite for anything.