I think you, and the agile software industry as large, are completely mistaken. There is absolutely no problem with intensive up-front analysis. In fact, this

I think you, and the agile software industry as large, are completely mistaken. There is absolutely no problem with intensive up-front analysis. In fact, this is what at least 80% of the effort should go into. But we have pretty much 0% staffing for that role. It's no wonder something doesn't work when no one's there to do it. Compare that to M&S in civil engineering. Regarding the alleged downsides: Any wrong implementation will incur massive cost down the road (but that cost usually is not accounted for in a SaaS world), so you actually cannot afford to not do it. Assumptions can change, yes, but at least you make assumptions. In agile development, people simply ignore any assumptions and end up with a completely broken product that eats 80% or more of development time with maintenance. And of course, planning and analysis can involve prototypes and iterations. I came to the conclusion that agile development just shifts the blame for bad planning from management to engineering. And I also think that the correct framework to planning and analysis is domain specific. The more constraints your domain enforces on your software, the better your analysis and estimation will be. Hence greenfield projects have the most problems.