I have worked on many Waterfall projects while at a defense research lab in the late 90s / early 00s. For several projects, it worked quite well, though none of this has anything to do with Waterfall being good. Waterfall is pretty bad, but success is at least possible because it allows for long-term commitment to a plan that can’t (as) easily be subverted by politics as in Agile, where politics doesn’t even need to do the pretense of coming up with an excuse because the built in excuse to mandate ill thought out context switches is ever present.

What I have seen really work are self-organizing policies where teams decide on their needs on a rolling basis. No prescriptive requirements.

For example, Agile might suggest teams can determine what type of sprint length matters for them, within some generally narrow range of sprint lengths.

But a good process will have no concept of a sprint or regular cadence, since it will be allowed to be different for each person and vary by project.

Another example may be that Agile offers flexibility to do research tasks as “spike” tickets or time-boxed regular tickets, so that the scope of a research task is forced to fit in with the iterative nature of Agile.

But a good process will not define a limit on the scope of a research task and will trust the engineer or implementer to choose when to curtail the scope based on the that person’s trusted understanding of the trade-off of probing more vs doing work on some other area, and that other people are likely not in a position to know better if more research investment is better than context switching.

Agile might suggest that at the completion of every sprint, the overall project is in a deployable / shippable state.

A good process would instead defer to the engineers or researchers to own the decision on a case by case basis about whether extended “partially implemented” states are better than the intermittent overhead of needing each change to satisfy delivery constraints.

Basically Agile pays lip service to infinite flexibility, but in reality is quite dogmatic about prescribed process. With Agile you are “free to customize” a series of prescribed global properties like fixed cadence, iterative delivery, etc., but you’re not actually free to arbitrarily disregard those things at whatever moments you need to disregard them.

The minimum condition of any good process is that the engineers and implementers are empowered to ignore and override any and all aspects of the process’s prescribed requirements at any time for any reason, and that the principle thing the business does is to trust the engineers and implementers to selectively disregard fixed processes at the exact moments when doing so is what’s best for the product & customer.

For example one way that Waterfall permits this where Agile doesn’t is to allow engineers to refuse scope change requests from customers. It can be crucial for making a customer happy to tell them “no” and refuse to change your existing plan in the face of new requests. You won’t always do this, of course. Often you will make changes that customers demand. But a good process leaves that freedom to veto a customer request up to the engineers and trusts that they won’t abuse that freedom. Agile on the other hand intrinsically revokes that freedom and takes the attitude of not at all trusting engineers to make that decision.

Agile, despite the lip service, categorically disallows this by its very definition, all the way back to the Agile principles themselves.