[kuschku]

I commented on it before in a sibling comment.

Also, please link the actual manifesto, not the intention behind it.

And that can be paraphrased as "People over tools", "Documentation doesn’t matter as long as it works", "Who needs a contract? Just collaborate with the customer!", "Plans? Why? Just follow the latest trends!"

And I have to disagree with them in every single point.

Documentation > Working Software (as others then can write their software interacting with yours before you are done),

Contracts > collaboration (if you want me to stay longer to do something, expand the contract and pay me extra),

Plans > change (if you just follow trends without ever structuring your design, you’ll end up with lots of code and no single person understanding all of it)

http://www.agilemanifesto.org/

[rjspotter]

That is not Documentation that is Specification. How do you Document something that isn't built yet unless you have perfect foresight? Last I checked humans could not yet perfectly predict the future. Thus, the value of Working Software that can be interrogated and probed vs "Comprehensive Documentation" that may or may not be based on wishful prospection.

The Manifesto values Collaboration over "Contract Negotiation" leaving off the Negotiation part is a straw-man argument.

Similarly, "Responding to Change" it is not the Change that the Manifesto values it is "Responding to Change". What it values "Responding to Change" over is "Following a Plan" not making a plan or doing any planning.

[kuschku]

Usually, you can decide on structure of code before implementing it. You can even have tests up and running before implementing it.

And in many cases this actually works.

[dustinleblanc]

You can do agile test first too.

"hey here's a feature we're pretty sure we need:

As a foo, I need to bar, So that baz

okay, write the test, make the test pass, refactor"

What about that isn't possible in agile?