I would argue that it's more correct to say something like "Not all software development done right is like that." Or in other words, some software development is closer to that model.
Some teams are doing work that involves real "invention", things that require using cutting edge C.S. research, implementing algorithms from papers, or using just-released open source libraries, etc. Other teams are building the nth iteration of some CRUD application that amounts to a database, some REST API's built using Spring Boot, and a UI built in React, where today's work isn't (usually) that different from yesteday's work.
Depending on which end of that spectrum your project falls on, it would make sense that the details of the methodology you use would need to vary.
I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work.
Unfortunately, I have found that few shops take either of these factors into account.
I think this is basically true but incomplete; early and late are misleading a bit, because it can be early in the life of a product that is in a well-explored space and it will look “late”, while a product can experience change in requirements or external context which makes it look “early”. A product should expect to move between modes multiple times if it is long-lived.