The book "How Big Things Get Done" by Bent Flyvbjerg nicely answers all the concerns mentioned in this thread. I'll answer here to avoid littering replies everywhere.

> But I do still think there's a lot of value into coming up with a good plan before jumping in.

Definitely, with emphasis on a _good_ plan. Most "plans" are bad and don't deserve that name.

> be specified up-front, planned on JIRA

Making a plan up-front is a good approach. A specification should be part of that plan. One should be ready to adapt it when needed during execution, but one should also strive to make the spec good enough to avoid changing.

HOWEVER, the "up-front specification" you mentioned was likely written _before_ making a plan, which is a bad approach. It was probably written as part of something that was called "planning" and has nothing to do with actual planning. In that case, the spec is pure fiction.

> estimates provided

Unless this project is exceptional, the estimates are probably fiction too.

> and Gantt charts setup

Gantt charts are a model, not a plan. Modeling is good; it gives you insight into the project. But a model should not be confused with a plan. It is just one tiny fragment you need to build a plan, and Gantt charts are just one of many many many types of models needed to build a plan.

> before they even sign the contract for the next milestone

That's a good thing. Signing a contract is an irreversible decision. The only contract that should be signed before planning is done is the contract that employs the planners.

> Anyone who claims upfront specs are the solution

See bove. A rigid upfront spec is usually not a plan, but pure fiction.

> My approach, especially for a project with a lot of unknowns, is usually to jump in right away and try to build a prototype.

Whether this is called planning or "jumping in" is a difference in terminology, not in the approach. The relevant clue is that you are experimenting with the problem to understand it, but you are NOT making irreversible decisions. By the terminology used in that book, you are _planning_, not _executing_.

> after the 2000 pages specification document was written, and passed down from the architects to the devs

If the 2000 page spec has never been passed to the devs while writing it, it's not part of a plan, it's pure fiction. Trying to develop software against that spec is part of planning.