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.
In reply to Re^6: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by JavaFan
in thread "Bah! Scrumbug!" (Lessons from the scrap-bin)
by locked_user sundialsvc4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |