You’re right that customers don’t know what they want and that can make it a bad idea to include them in the dev process directly. But is that what Agile is about? I thought it was about iterative development. As a long time product dev I know that you want to follow your own vision when building your product. You let your vision be influenced by customer feedback for sure, but you should always second guess the feedback, never take it at face value, never just build something because a customer asks for it - that would be Henry Ford trying to breed faster horses.
It's probably better to phrase it being a development method that focuses on a tight feedback loop with all stakeholders.
You push decisions as far out as possible and gather feedback from individuals every step of the way.
This is what allows the greatest amount of flexibility.
The biggest problem with agile is that it assumes all problems can be put off to the last minute.
I'm frequently finding myself in situations where it is 100x better to hammock program it out for a few weeks before pushing any code. Those systems last ten years. Those systems are able to be modified simply and quickly when business needs change. Those systems do build up legacy code, but it's at a slower rate than other systems. Those systems have fewer hacks over time and fewer bugs as a result.
This isn't a dig at agile, it's a dig at using agile as a design process, for which it is utterly inept. Agile is great at pushing products, terrible at pushing thoughtful system design. (On average, sometimes working a problem works too but more often than not you don't get the chance to redo middle sprint 5.)
