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.