Ok, to call it the "physical/organization structure" was probably too literal.
What I'm getting at is what I've seen from waterfall, where responsibility is "handed-off" from department A to department B to department C and then it's "done".
Managers use the waterfall phases to schedule each department's workload, so each team is essentially working in isolation.
e.g.: "Requirements and Design" is one department, "Implementation" is another, "Verification" is yet another. (Design, Developers, QA)
This used to be the standard practice where I worked doing client web development. Random Fortune 500 Company is not going to buy into an iterative development process, because the person at the client company is usually some peon with little real power to adjust budget or requirements as necessary. That is, until it's too late, and their superiors are breathing down their necks because the website doesn't do what they didn't say it should do. Plus, if you don't use an iterative process, you can bill your client for massive change orders.
So there's no real incentive on either side to change the process, unless both companies "get it" from the start that you can't make quality software this way. The likelihood of this decreases dramatically the larger the client.
What I'm getting at is what I've seen from waterfall, where responsibility is "handed-off" from department A to department B to department C and then it's "done".
Managers use the waterfall phases to schedule each department's workload, so each team is essentially working in isolation.
e.g.: "Requirements and Design" is one department, "Implementation" is another, "Verification" is yet another. (Design, Developers, QA)