The task being spelled-out here is also pretty much one program being done by one person who is more-or-less fitting it together by feel.

What utter rubbish. The top level "program" might be might be a single standalone application. Or it might be the home page of a new website. Or the first subpage in a sub-application. Whatever the form of the application, there is a top level, that structured programming suggests, is itself relatively simple, but which dictates considerable influence over the structure and interfaces of the next level of components.

Once that level has been laid out, excercised, demonstrated and approved--usually a matter of hours or days--a team of any size required can start working on the internals of the next layer deeper, as their interfaces with the top level have been defined. And the documentation people can start documenting the top level straight away, in parallel. This isolation of concerns reduces coupling (the Holy Grail), between the lower levels and allows the teams to operate free from co-dependancies upon each other.

The process works just as well for a team of 720 people as it does for one, because the interfaces between each subgroup are clearly defined. Even when those interfaces need to change, whether through customer requirements altering from above, or implementation requirements from below, the changes and negotiations they require are isolated to one vertical path through the development, not scattered throughout the project. Meetings are smaller, decisions are quicker, parallel paths continue unaffected.

The hierachal breakdown of projects into sub-projects falls out naturally from the design process, rather than being artificially imposed from on-high by capricious whim. At the end of each day, each sub-project has a working program. The top level works, because each of it's dependants are mocked up. Each of the sub-groups substitute their part for its mockup in a copy, and can develop and test independant of each other.

Only once they are happy with their testing does their part get integrated back into the top level. And if it breaks, the top level reverts to using the mockup, allowing it to continue to test other interfaces as they become available, until it doesn't. At any given point in time, each group can continue to develop and test their part in isolation of others, because the interfaces are clear, and have been mocked up early.

Catastrophic failures--through code failures, death, holidays, staff changes, server failures, whatever--are isolated to just the affected sub-project and so do not bring the entire project to a halt as with set-in-stone development plans.

Regardless of whether you use an OO, procedural, or functional design philosophy, or which languages you use, the decoupling of dependancies through interface isolation, is the key to project control and management. RAD allows projects to move forward faster and respond to requirements changes earlier and more easily.

The idea that requirements can be gathered completely up-front, signed off and never change belies the realities of modern life. The last really big project I architected had to change track in late mid-stream for purely political reasons. An election brought about a change in flavour of government, and the project leader was called in front of a standing committee to explain why there was so little regional involvement in the project. The hierachal RAD development philosophy allowed the project to respond to the changes mandated by parliament with minimal delays to the overall project timelines.

I cannot imagine re-carving the stone tablets of a waterfall development project plan, in similar circumstances, without it having a huge impact on timelines and costs.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

What you are describing is a multi-tiered project plan, and it's a good one as evidenced by your team's very obvious success. I am not going to argue that such success is an “accident.” But neither am I going to agree with what another previous poster suggested, “no guts no glory.” I've seen the code that I wrote at 3:00 A.M., and it was pure crap.

Going back to the construction analogy, which I maintain is very apt, it is certainly true that the master-plan is exploded to a series of sub-plans such that each of the individual teams can then pursue their work in parallel with one-another. Many projects lend themselves well to this sort of de-coupling and they are designed so to be.
Working teams need to be reactive while they are working, and to achieve quick (preferably daily) closure of their assigned tasks, but teams that are tasked in this way can only be successful when the change that they are considering falls entirely within the scope of what they are doing.

If the workgroups “never encounter a problem,” the project is well-managed.
If they “never encounter a problem” and think that it could never occur, then the project is very well-managed, by someone who's happy to let the developers take all the credit for what they'll perceive to be singularly their success.
Only a really-great executive can achieve that.

I personally don't see a conflict between what you are saying and what I am saying, and I'm not suggesting “my way or else.” Instead, it's two aspects of the very same beast. “Rapid Application Development” is a laudable thing up to a point, but it can also devolve into “a rush to code.”
Methodical and explicit exposition-work is just as much a part of the programming process as is the writing of subs.

The best overall strategy is a blend of the waterfall-model and the more-parallel approaches.
And there's no transition between one and the other.
They occur at the same time.
The high-level discussions take place “under the waterfall” while the individual work-components are being dispatched to the workgroups in these more-parallelized ways.
The two are kept in-sync.

Workers need to see quick-closure so that they can see what they are now aiming-at, just as construction workers install a unit and promptly tie it down. They need to put stubs in-place so that they can replace the stubs in a “successive refinement” strategy. Also, even high-level stakeholders need to see “something that moves” as soon as possible because their visualization skills are probably less-honed. “Show me.” Nevertheless, unless management at both of these levels is being maintained, a project can fall into anarchy ... with sleeping-bag results.

Ada Lovelace for the palindrome
Albert Einstein for having smelly feet
Alfred Nobel for his contribution to battlefield science
Burkhard Heim for providing the missing link between science and mysticism
Claude Shannnon for riding a unicycle at night at MIT
Donald Knuth for being such a great organist
Edward Teller for being the template for Dr. Strangelove
Edwin Hubble for pretending to be a pipe-smoking English gentleman
Erwin Schrödinger for cruelty to cats
Hedy Lamarr for weaponizing pianos
Hugh Everett for immortality, especially for cats
Isaac Newton for his occult studies
Kikunae Ikeda for discovering the secrets of soy sauce
Larry Wall for his website
Louis Camille Maillard for discovering why steaks taste good
Marie Curie for the shiny stuff
Nikola Tesla for the cool cars
Paul Dirac for speaking one word per hour when socializing
Richard Feynman for his bongo skills
Robert Oppenheimer for his in-depth knowledge of the Bhagavad Gita
Rusi P Taleyarkhan for Cold Fusion
Sigmund Freud for his Ménage ā trois
Theodor W Adorno for his contribution to the reception of jazz
Wilhelm Röntgen for the foundations of body scanners
Yulii Borisovich Khariton for the Tsar Bomba
Other (please explain why)