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.