3 ms·

I thought agile “fixed” waterfall because waterfall had all this effort go into a product only to get feedback at the end, which to me sounds like a failure of

I thought agile “fixed” waterfall because waterfall had all this effort go into a product only to get feedback at the end, which to me sounds like a failure of product not engineering. By having tighter feedback loops it was promised less man-hours would be spent. My impression is it’s changed what the man-hours are spent on. It’s harder to get an elegant architecture over 2-3 years of agile as opposed to waterfall where it can be more tightly controlled. That’s probably the limit of my perspective on the matter. I am positive there are others that know more and have a more accurate perspective on why and how things changed.

Zigurd 3y ago
This "waterfall had all this effort go into a product only to get feedback at the end" was Winston Royce's own diagnosis of the problem with the waterfall model he formalized. That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile. You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs. A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc. More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.
- Zigurd 3y ago
  Here is Royce's statement on his own waterfall model's risks: I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
  - rawgabbit 3y ago
    This is the crux of the issue. A CIO once asked me what I thought was the most important factor for a software project to be successful. I told him good requirements. The CIO proceeded to lecture me with Agile you don’t really need requirements. I thought he was full of shit. It is the same thing as answering a question in the SAT exam. If you don’t know the question (requirement), how can you answer the question? This is truly nonsensical Orwellian logic. It is communism.
    - Zigurd 3y ago
      Real Communists use Gantt charts. Henry Gantt's colleague Walter Polakov brought "scientific management" to Soviet 5 year plans.

Zigurd 3y ago

This "waterfall had all this effort go into a product only to get feedback at the end" was Winston Royce's own diagnosis of the problem with the waterfall model he formalized. That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile. You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs. A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc. More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.

Zigurd 3y ago
Here is Royce's statement on his own waterfall model's risks: I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
- rawgabbit 3y ago
  This is the crux of the issue. A CIO once asked me what I thought was the most important factor for a software project to be successful. I told him good requirements. The CIO proceeded to lecture me with Agile you don’t really need requirements. I thought he was full of shit. It is the same thing as answering a question in the SAT exam. If you don’t know the question (requirement), how can you answer the question? This is truly nonsensical Orwellian logic. It is communism.
  - Zigurd 3y ago
    Real Communists use Gantt charts. Henry Gantt's colleague Walter Polakov brought "scientific management" to Soviet 5 year plans.