@Bediko The problem is that in many projects requirements are indeed changing every two weeks - and the important ones are often implicit and unstated. That breaks every project management approach, not just agile. Agile works if you have flat boring feature sets on top of an existing suitable data model, and a product owner who actually wants to use (not sell) the product.
@StephanSchulz @Bediko I always wonder why nasa can send things pretty far away, remote debug over 100k of kilometers and people still claim that working software can’t be done or that planning does not work.
@jnfrd @Bediko They spend an ungodly amount of money per line of code - and that includes requirements engineering (not a brainstorming session among whoever was there at the moment). Front-loading projects sometimes works, but is hard to sell. I once promised to do a project with 3 engineers in 2 years. Management went with the guy who promised to do it in half. 4 years later I left the company, and the 5 engineer-staffed project was still far from useable.

@StephanSchulz @Bediko yes. But things aren’t black and white and I think one can find a sensible middle ground.

Also. An iterative process can be a very good fit for software development. It shouldn’t involve sprints though. And no tshirts either.

@jnfrd @StephanSchulz @Bediko a “sensible middle ground” between NASA’s budget and the average software company’s budget is functionally just still NASA’s budget. They are operating at different orders of magnitude. Conservatively, NASA spends 2000% more per line of code than the rest of the industry and I believe this is still a huge undercount: https://www.nasa.gov/history/sts1/pages/computer.html#:~:text=In%20an%20industry%20where%20the,development%20and%20support%20of%20PASS.
computer

@glyph @StephanSchulz @Bediko there is a lot of space between no planning and just iterating senselessly until the project grinds to a halt, and nasa.

@glyph @jnfrd @StephanSchulz @Bediko

That is from the later 1970's. The time, when computing was relatively new.

Nowadays, NASA doesn't need to work on, if software works. A lot of frameworks exist with a lot of known best practices.

The gap between NASA and other software developers is still enormous, but this ratio is most probably outdated.

@StephanSchulz @jnfrd @Bediko I read somewhere (maybe it was Feynman) that code development speed for the Space Shuttle was about 1 (in words: One) line of code per week.
@hopfgeist @jnfrd @Bediko IIRC, "The mythical man month" has something like 10 lines per programmer per day, for production-quality code. And independent of the language, so high-level languages do give a boost in functionality per time...