Nope. Waterfall is still used and used correctly in situations where there are large and important contractual or compliance obligations. You wouldn't use an agile methodology in construction, you waterfall the hell out of that. Same for hardware projects where fab times can be very lengthy.

I don't blame you for coming to the conclusion you have, but you'd do well to signpost when you suspect something is true vs have reason and evidence that something is true.

> You wouldn't use an agile methodology in construction, you waterfall the hell out of that.

On the contrary, Mary Poppendieck has a wonderful presentation she gave on how the Empire State Building was built in record time by literally doing it as a more agile-style construction. https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...

Likewise, American manufacturers by WWII had already gotten very good at building complicated machinery based on relatively light levels of blueprints and documentation, with the detail-level designs being added to the drawings used on the factory floor.

In many ways we have to blame the introduction of computerized project management for waterfall... it simply wouldn't have been workable before that to even attempt a real waterfall method for projects.

I won’t wade into the intricacies of defining Waterfall or whether it has merit, but it definitely should be mentioned that Kanban—a capital A Agile technique which most capital A Agile advocates find unstructured and unpredictable (as in tends towards lowercase a agile)—was popularized by an auto manufacturer, where safety and liability are at least as much a concern as construction.

Kanban is a core but small part of TPS, it can't be said to be pro or against safety.

> > was popularized by an auto manufacturer, where safety and liability are at least as much a concern as construction.

> Kanban is a core but small part of TPS, it can't be said to be pro or against safety.

The poster's point is that it's not obviously defective from that standpoint, despite criticisms that imply that it is.

Almost exactly my point. There’s a fairly strong set of evidence that it’s safety-neutral at worst.

I love kanban. It's not perfectly suited for knowledge work, though. Great for smaller projects and for places where precise scoping and predictability is less important than just making progress.

Does Waterfall as used today test software during subassembly development, if so its not https://en.wikipedia.org/wiki/Winston_W._Royce 's waterfall.

Waterfall was not the name given by Royce to the multi-stage model of software development but it's easy to see how it got called that. Boehm called it "Waterfall" and used it as a foil for his own ideas in the spiral model, which was a pretty good description of a "middle-out" sort of process with an emphasis on feedback and customer support.

The Royce paper saw the one-shot waterfall as unrealistic even with the project alternating back and forth between phases. It ends with a complicated-looking process of writing two systems. Estimation of time to completion or cost is not really solved there.

But really what people mean when they refer back to Waterfall is the idea that you can put a reasonable upper bound on cost and time to completion of a larger project while keeping a maximum lower bound on functionality/scope.

Even in the 1980s, people were looking at business software systems and thinking they were pretty well defined in terms of complexity. A database, a bunch of data entry and data retrieval screens, some online functions, some batch functions. Maybe you could specify these like a builder specifies a concrete sidewalk. (A literal example from a software engineering book). Then estimation should be possible.

The trouble is that the requirements of a multi year project are often out of date before the project is started and many specifications are underspecified until the customer has seen something like the final product. So why not plan around change? Bound the budget, allow some schedule time, and see how much functionality can be built in that time. Let the customer prioritize parts of functionality and the developers work smoothly, and the whole team can stay in a mode of delivering functionality frequently.

Royce 1970. https://dl.acm.org/doi/pdf/10.5555/41765.41801

Boehm 1986? https://dl.acm.org/doi/10.1145/12944.12948

Unfortunately it is still practiced in many environments, including most Navy software acquisition efforts, which are frequently run under a "systems engineering" process intended for hardware like ships and airplanes.

This process includes multiple reviews in a "SETR" (System Engineering Technical Review) process (https://www.acqnotes.com/Attachments/SETR%20Navy%E2%80%99s%2...), including steps like:

* SRR (System Requirements Review)

* CDR (Critical Design Review)

* TRR (Test Readiness Review)

Example of slide 15:

Example of Items from SRR Template

* SW Development Team

* Integrated Mater Schedule Highlighted with Software Milestones

* Software Entrance Criteria

* Requirements Analysis and Allocation Methodology (sounds agile to me!)

* System Specifications Tree

* Contract Data Requirements List (CDRL)

* Software Development Strategy

* Software Development Process

* SW Safety, Information Assurance and Security requirements

* Software Supplier Management

* Software Measurement

* Software Risk Assessment with Mitigation Strategies

* Issues and Concerns

> Waterfall is not practiced

Is this anecdotal or what? "I want the citations."

Waterfall was first coined as a smear for as far as I can tell "planning too much": https://en.wikipedia.org/wiki/Winston_W._Royce

That's super interesting and I didn't know this history. However, misinterpreting someone's ideas doesn't make it not real if people are actively practicing them.

The link is the man who coined the term. Would you say waterfall today is strictly adherent to NOT testing code before delivery of subassembly? That's the coiners definition.

No, I'm saying that the article states that waterfall, _as is used today_, was misattributed to the coiner, and that's about all it says. That doesn't mean that waterfall doesn't exist and it certainly doesn't prove that the agile folks invented waterfall to have something hate on.

I've never worked somewhere that did waterfall. But I did have classes where waterfall was tought as the way to do software development.

I used to work in banks where you had teams of architects create high level design (HLD) docs that get turned over to the design team to produce low level designs (LLD) that the get turned over to developers how are meant to write the code, then to be turned over to the testing team. With massive handover meetings at every stage and forests of paper for milestone documentation that had to be signed off.

Never had my soul be destroyed as completely and I seen such a massive waste of time and money.

Waterfall absolutely was practiced. Budgets always overrun and developers had to work overtime to meet deadlines completing all the tasks that weren't mentioned in the plan.

This still happens under agile too. It’s not like a process magically fixes things. Most of the issues I read from SWE in regards to agile is that they are often neglected in both decision making and the ability to hold leadership accountable.

No amount of agileness is going to save you from a miss managed team.

Well I wouldn't count mismanagement against agile then. At my work we practice SWE by managerial dictatorship and also "agile." I'm certainly not holding the failures against agile.