Re:Requirements do change (Score 1)

If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building." At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.

I don't see it the same way. One the one hand, if the requirements keep changing, developers must change direction, too. What's the point of delivering something that no one wants anymore? If your goal is to deliver functionality that the market no longer wants, then your business will go out of business. Fast.

But this "contract" between developers and the business team is not one-way. The business development team _must_ define good requirements. Typically this means delivering _small_ features and getting customer feedback frequently. But if the business team tells the development organization to "build Rome" and then two weeks later they tell you to build Toronto and then two weeks after that they tell you "No no no, build Rio," of course the developers will fail. Rome wasn't built in a day, and big software is not either.

Also, Agile tends to assume that everything can be broken down into subtasks that take only a single iteration to complete. In practice, this is not always the case, particularly with complex software.

I disagree. Is managing complexity not the point of software engineering? To break complex components into smaller components and then "assemble" systems? You can't deliver Rome in a day, but you can deliver a road, or an aqueduct, or a market place. The _cumulative_ result of all the iterations is the ultimate goal, but for one iteration, you deliverable is much smaller.

Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer. Because the design work is done iteratively, it is very easy to go off on tangents and iterate on some part of the design, while failing to design the whole.

Again, I disagree. Because you are iterating, it should be _difficult_ to go off on tangents. When you are done with your (short) iteration, you ask yourself, "What should I work on next?" A sane organization will choose to work on the most urgent task. A sane organization will not choose to work on a tangent.