That could apply to waterfall also. You build all specifications and understanding up front, then you implement it to the specification.

My opposition to waterfall is that building understanding through investigation and specifications is inferior as a way to get the finished product you need in the time you want, generally much inferior than building understanding through implementation.

But I've always seen that somewhat orthogonal to team-level processes.

You can "Agile™" or "Scrum™" the shit out of waterfall, after all. Create a ton of tickets for spec writing, etc.

The whole point of Scrum, in my opinion, is to create a working increment in the sprint. That’s the mechanism for managing risk. Finishing tickets for writing specs don’t achieve that. Unfortunately, it’s a common practice though.

Yeah, having running software forces you to prove a certain level of correctness and lets people test against it.

You can call a spec done arbitrarily and it's much harder to test that spec against any number of edge cases; and harder to visibly inspect "do these two specs get along" than "did this API call to this other place succeed?" "It doesn't compile" or "it throws an error" or "it doesn't do what it should" are all much more concrete and force you to confront "we might not understand the problem as well as we thought."