Scrum is the new waterfall

Agile only makes complete sense when you take it in its historical context as a reaction to other methods, not as a standalone methodology with no history that sprang wholesale from the ground. It's not "this sounds good, let's try this", it's "we tried the other way and it did not work, we need to do something different".

Saying that you have something that works (an MVP, for instance) is _more important than_ documentation. That doesn't mean you shouldn't have documentation. Documentation will always lag behind actual code unless someone is full time updating documentation, which I have yet to see happen anywhere.

And even if you have documentation - it is an agreed communication of intent. The problem is, not everyone is necessarily reading it in the same way, or communicating their intent very well, or realizing inconsistencies and hurdles in what they've communicated. So when you actually have to write the software - you find you can't do it the way it was proposed, the way it was proposed is less efficient or fault tolerant, conflicts with other parts of the design, or is just ambiguous in a way that causes the developer to code up something other than was intended.

In a waterfall design, you wouldn't find out about the ambiguous bits until you present it to the client - at the end of the cycle when it's quite possibly already too late. In an iterative development cycle you can get constant feedback and more easily react to change. That's what agile is really all about.

Change is inevitable - agile attempts to recognize this fact and work as quickly as possible to create a product and immediately and incrementally improve upon it, keeping things moving forward, rather than spending huge amounts of time fussing over details that maybe won't make it into the final product while missing huge discrepancies or 'unknown unknowns' that aren't well understood until something is actually written.

Maybe I've had a twisted experience of Agile, but it seems like its most useful when you are working on a greenfield project, with a customer that maybe doesn't even know what they want, but they know they want something. So you get some requirements, and build a prototype. Then you show it off, and they make some comments, (generally like: "Can it run in the Cloud? Is it Social?", "Could that icon be more of a cornflower-blue?"). Sometimes you get useful feedback also... Then you go back and refine the prototype. Rinse and repeat, and eventually it does enough that they are happy.

Even when you do know "exactly" what you are building, I would still prefer starting from a bare-bones version, and building out from there. Unless you've built this exact thing before, planning it all out beforehand will invariably miss some Rumsfeldian unknown-unknown technical detail, which might tip up the whole apple-cart of the carefully, laboriously, expensively, laid-out plan.

It's not like its 1995, and releasing a software version involved burning thousands of CDs, printing manuals, boxing it up, and distributing the boxes to retail stores. And most of us are not launching the software we write out beyond low-earth orbit.

but almost always Agile leads to this issue. Even the previously linked NASA document says their spaceflight software should have a release and update schedule with feature updates similar to Google Chrome (aka, no support for old versions at all, always the newest, shiniest)

"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?

You can accomplish this with agile development:

1. People meet at the beginning of the project and say "heres what we think our washing machine needs"

2. They create a backlog based on those features

3. They start working and implement some features.

4. They find out they don't actually need the washing machine to wink and smile and say its done in a fancy british accent. It was a silly idea marketing came up with that adds no value. They drop that feature from the backlog.

5. They find out making the machine text you when your laundry is done is a desirable feature, they add it to the backlog.

6. Management says the competitor is launching a month earlier than us so we need to accelerate the time table. Engineering gives them the hard news that they need to sacrifice some features. They look at what they have left to do and prioritize the important items and drop the feature for the washer tie-dying your clothes if you want from the backlog.

6. Project enters qa, all tests are passing but testers found a bug. They write a test to confirm and reproduce the bug, they squash it and update the build.

7. Software is working, launch happens, everyone celebrates.

Nothing here says the software has to change anymore; its done, its shipped, its good to go, and done using scrum/agile.