Re^6: "Bah! Scrumbug!" (Lessons from the scrap-bin)

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.

Comment on Re^6: "Bah! Scrumbug!" (Lessons from the scrap-bin)

Replies are listed 'Best First'.
Re^7: "Bah! Scrumbug!" (Lessons from the scrap-bin) by mr_mischief (Monsignor) on Dec 17, 2010 at 19:25 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^7: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by mr_mischief (Monsignor) on Dec 17, 2010 at 19:25 UTC

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.

[reply]