That high level of complexity is where standards come into play. You can recreate the whole thing several times for a small, isolated project. You might do a house, a subdivision, or even a small village as a planned community.

Yet when you get to things like cities, nobody implements the whole thing as one team. You have a zoning plan enforced by one group, a street plan sometimes enforced even separately from the zoning plan, there are building code requirements for all buildings in the city (with certain waivers and exceptions being made by application and consideration), permits must be issued for certain kinds of work, and some of the people involved in certain types of sub-projects must be licensed in certain jurisdictions.

There's an electric utility, a water utility, a sewer utility, a gas utility, a cable company, a land-line phone company, a cell company, an Internet access company, a trash service, a recycling service, and maybe a heating oil, LNG, or LP company. Some of those might be part of the city government. Some might be combined to provide more than one utility from the same company. In some cases their may even be some competition within the same city.

I'm not sure waterfall was all wrong. It certainly wasn't all right, but I'm not sure it was all wrong. Maybe sometimes the general plan should be handed down from senior staff to separate teams. Those separate teams might work better bottom-up on their part of the project. It's often important, though, for the data interchange among the different teams to be standardized.

One mess I've often seen is that one part of an application handles the same data along completely different lines from the rest of the program. Encapsulation being good, that's not a problem internally. Externally, though, where it interfaces with other parts of the program, having a duplicate and wildly different API or data format is just a silly requirement for one team to impose on the others. Standardizing what data formats each piece of the project will accept makes much more sense if all pieces are being written from the start. Leave the munging and glue code to tying different projects together.

Another place large projects sometimes really suffer from a lack of standardization across the project is in end-user interfaces. Features can get duplicated. Similar features can have surprising differences in their behavior. Sometimes different parts of the program even accept input in a different way than the user has come to expect from using the rest of the program. There's no need for any of that. You can develop a part for a larger whole in a different fashion under a different methodology and still put together pieces that fit in the larger project.

I think the biggest failings of Waterfall and of Structured Programming are in thinking that you can drill down exact specifications arbitrarily far. I think, likewise, that the failings of bottom-up methods like some agile methods and some lean methods try to be are in thinking you can implement and revise all the way up.

I think if you're working on a large enough project, then sometimes it's good to have a set of rules to implement toward from above when you're working up from below.

I'm not sure waterfall was all wrong. It certainly wasn't all right, but I'm not sure it was all wrong.

Dr. Royce was certain it wasn't all right.

I'm not sure waterfall was all wrong. It certainly wasn't all right, but I'm not sure it was all wrong.

I don't think it's a matter of right or wrong. It's important to recognize which method (be it waterfall, agile, something else) is suitable for which company/organization/project. What I do not is wrong is take an example of a production process which allows to partial redoing of the produce, and use that to show agile methods don't work on the design and implementation of a single product.

I think the biggest failings of Waterfall and of Structured Programming are in thinking that you can drill down exact specifications arbitrarily far.

I fail to see what "Structured Progamming" has to do with any of this. "Structured Programming" (that is, using blocks with single entry and exit points), is neither required nor prohibited by either Waterfall (or similar techniques) nor by any Agile method.

I think if you're working on a large enough project, then sometimes it's good to have a set of rules to implement toward from above when you're working up from below.

Scrum, or any agile method, does not mean big projects cannot be worked on (usually, big projects are collections of features), or that teams are kept in the dark of the big project their sprint is contributing to.

When you choose the single simplest possible definition of Structured Programming outside of any context, you're right that it is allowed but not enforced by most management and implementation methodologies. It is orthogonal to them in this simplest "single entry and exit points" definition. There are, however, several structured programming variants and families of variants that impose far more rules than that. Jackson Structured Programming structures the program around the input and output very strictly, which produces programs very unlike Dijkstra's. Ken Orr and others took Dijkstra's work and headed toward Structure_chart ( a very specific type of chart that combines a flowchart with the organization chart for the program's parts) and other top-down design methods.

I never said agile can't work on a single product.

Working on a program as a collection of features can be a problem if there's not some other specification. That's the problem with going too purely towards bottom-up in both design and implementation. If you work on a program as a collection of features tied together by a well-specified central foundation each feature hangs from and communicates with, it can work beautifully. If you have a large enough collection of features with no over-arching standard for how they interact, you get a bunch of bells and whistles that work poorly together for the user and possibly for the maintainer even if they pass all the integration tests.