Doing waterfall in the exact sense that is usually described will almost certainly never work well. People usually focus on the design phase, but I think the much more catastrophic part of 'waterfall' is doing testing only once development is complete.

Now, you absolutely can successfully run software projects that are design heavy, that more or less freeze requirements and designs early on, and that seek to execute on the design, instead of iterating. However, if you truly develop for 6 months before any kind of external QA, as described in most Agile talks about what Waterfall means, that is a recipe for disaster. If you do test things by feature, invest in component testing and practice that all along the way, you can succeed.

This essentially describes a 2-stage waterfall: design and execute, where the execute phase includes both development and testing all along the way. Is this 'doing waterfall properly'? Or is it a hybrid methodology? That's a matter of definitions in the end.

It's also important to note that the extent to which this works depends a lot on the project itself. If the requirements are volatile (e.g. when developing a new product with an uncertain market), or if the project is too large (e.g. if the design phase suggests it will take 5 years to finish given the current team), then it's likely that the project would benefit a lot more from an Agile style of development, where you deliver smaller chunks of the project to its end users to gather early feedback on the actual usefullness.

In my experience, waterfall needs unlimited time and money. Waterfall fails hard when money or time are limited, in which case the likely outcome is that the head of waterfall will be massive and the tail will be rushed, so that one gets a design-heavy and rushed implementation with little or no testing and scant documentation etc.

A timeboxed waterfall with inflexible sculpted-in-stone time schedules are a recipe for burning in the ensuing deathmarch. The planning either cannot or will not anticipate all unknowns and/or the buffers dampening the impact of the unknowns shrink because of outside pressure. (What do you mean 8 months to make this thing, can't you do it in 2 weeks, haggle haggle, sold for 2 months; available time reduced by a factor of 4)

In contrast, (a theoretically ideal) agile or some other iterative method works fine if time or money are limited. The iterative nature allows for a cut-off after a sprint. Pull the plug and have a result of state-of-the-art at that point; of course the result then might not quite reach the viable dimension of MVP nor even resemble a product.

"Work": I don't mean that the projects fail but that they fail in some aspect. Like they deliver late, or don't deliver the full requirements, or they don't deliver the real requirements (because the requirements were written 5 years ago by a consultant, this might be a total failure in many cases).

"agile" (not Big-A Agile the faddish cult) resolves a lot of this by one simple thing: frequent feedback between developers and customers while developing smaller increments. Which, ironically, was actually Royce's point in the paper: Feedback loops, not necessarily with the customer, need to be incorporated in order to develop large scale systems.

One of the issues in discussing this is that it turns out that when most people say "Waterfall" they mean a modified version. When you dig into what they're doing it's either a small modification (we bring the customer in during testing, which is good but that's still 4 years into the project) or a major modification (V-Model which incorporates all of Royce's feedback loops and then some). Others have gone to doing incremental & iterative development or evolutionary but still call it Waterfall because they don't know any other term.

But yes, Waterfall exists, it is a nightmare, and I hope to never be involved in it again.

That said, sometimes, Waterfall is the best way to do some projects, but I'd say very, very few. It does work reasonably well for hardware production. Many hardware companies apply Waterfall to software, because it's the process they know.

TDD is also a technique that can encourage a "waterfallish" approach, as the design needs to be fairly complete, right at the beginning (to be fair, it is possible to do TDD iteratively, but that takes effort, and many shops like to reduce effort as much as possible). I tend to keep my designs as fluid as possible, refining in a JIT manner[1], and prefer using test harnesses to fixed unit tests[2].

I personally have a beef with the way many shops handle the concept of MVP. I feel that a significant number of shops use it as an excuse to shove out a hastily-built lashup; favoring adding features to ensuring quality.

I have come to believe in the concept and purpose of MVP, but I am also one of those "grizzled, cranky oldtimers" that has seen many, many prototypes become the "heart" of applications, and even infrastructures. I won't mention some rather obvious examples.

I feel that it's important to ensure quality from the first line of code, and to accept the fact that the MVP will become the core of the system.

[0] https://en.wikipedia.org/wiki/Waterfall_model#History (Look at Royce's presentation)

[1] https://medium.com/chrismarshallny/evolutionary-design-speci...

[2] https://medium.com/chrismarshallny/testing-harness-vs-unit-4...

Our industry really jumped the shark with the Agile and XP nonsense. I flip the bozobit for anyone who uses "kanban", "sprint", liar's poker err planning poker, and other Dilbertspeak non-ironically.

20+ years later, best I can tell, the anti-methodology methodology Agile cargo cult band wagon was for people who couldn't be bothered to sit thru a PMI seminar. The unholy synthesis of pop-biz fashionistas and corporate climbers bouldering along the bullshit jobs facades. Artistes, pointy-haired bosses, "consultants", post dotcom era geek wannabes, and other assorted hangerons and poseurs.

I've always struggled to articulate the core problem. Agile is for those proudly belligerent ignorant people who reject expertise, wisdom, or anything else that would expose their grift.

A cult, more or less.

Buy me a beer sometime and I'll tell y'all how I really feel.

Well... why do you think it's made out to be the "bogeyman"? The reality is that people tried (and continued to try) to run software projects that way: state up-front everything you're going to do, and then do it! What could be simpler?

Anybody who's ever tried to do that has run headlong into the reality that: they didn't know up-front all the things they were going to need to do. For a long time, people believed that this was just a matter of experience and perspective and, after a reasonable amount of practice, software developers would be able to not only recite each task ahead of time, not only predict how long each was going to take, but would be able to do so in orders of magnitude less time than the actual task would take.

This view of software development imagines programming as mostly just typing without much more thought involved than, say, laying bricks. That this model, if accurate, could be automated away seems to escape the attention of the project managers who insist on managing software projects this way. If it were possible to specify software in such a way that it could be predicted and planned out the way "waterfall" demands, it could be automated to take humans out of the equation completely. (And the project managers themselves could be replaced with a spreadsheet).

If you go back and read the original Agile manifesto, it was written by people who were trying to explain that software is inherently unpredictable or - more to the point - that the parts of software that you need humans to perform are the unpredictable parts. There's an old saying, though, that nobody ever went broke telling people what they wanted to hear, so a cottage industry of agile "consultants" who'd never tried to develop software themselves made fortunes telling upper management that software is, as they wished, completely predictable, and the only reason schedules slip is because they're not mistreating their programmers harshly enough.

I've never seen a project use "Waterfall". It's just not a thing. People use it as a hypothetical boogeyman to "Agile".

As with everything "Agile", all words lose meaning.

Edit: There DOES exist the CMMI Systems Engineering processes, that generally involve various design reviews (PDR, CDR), IOCs, FOCs. These are essential for large-scale procurement that perform mission-critical functions. Superficially similar to "Waterfall", it still isn't. For example, you don't want to be on an aircraft or spacecraft that was "Agile"-ed to completion.

It's not fine if there is a need for the particular things that agile serves, which is why contracting requirements would specify agile and contractors would, to be response, claim to be agile necessitating the people reviewing the submission to detect agile BS.

Government requires waterfallish process in contracts all the time, but a document on identifying Agile BS isn't addressing those cases.

They used an enterprise-grade source control system run by the IT department (Perforce.) It was almost impossible to create a branch. In fact, I saw only one created during my brief 1 year time there.

Since there were no branches, you had "shelve" your changes and get an "in person" code review to merge. If you added something minor, like a new getter, but didn't have a unit test for it, you'd get flagged (even if it was used else where in the code.) It basically took forever to get anything done.

Oh yeah, they never shipped any of this stuff, either.

I could go on...

Functional teams and companies will make good products and set up their staff for success, with or without agile.

Dysfunctional teams will have all sorts of perverse incentives and set each other up for failure, with or without agile.

Made up of various tech industry leaders (mainly CEOs, it seems). The purpose was to try and modernize the way, or present a path to modernization, defense software systems are developed and maintained. Because it's presently a cluster fuck.

You can't force customers to "get" Agile. You can force them to understand the risks of not participating in the process.

My complaint would be that, "Tools listed/shown here are for illustration only: no endorsement implied," should have been inline instead of buried in a footnote.