[vbtemp]

Approximately 13 years in the field. At least four to five different organizations. Worked on everything from embedded aerospace systems to web apps and everything in between. Start-ups, mega-government labs, and again everything in between.

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.

[beh9540]

Waterfall is certainly a thing - although it's taken most of my career to run into it. Where I work currently (banking) some of the projects are waterfall, some are agile. The waterfall group has requirements gathered for them by the stakeholders, they build to spec, it's tested by the stakeholders after development is complete, issues are fixed and then it's deployed, all managed by a project management team. There's a series of "phase exits" that need to be signed off on by executives in a big meeting, and the project doesn't move backwards. Massive amounts of documentation are generated (and never read, except by external auditors) for every aspect of the application - every workflow, procedure and logic built into the application. Iteration doesn't happen at all, everything is a massive project, or bug fixes.

All the "boogeyman" activities happen - scope creep goes crazy, testing is run short to hit deadlines set, etc. Like you I never really thought it was a thing until I saw it with my own eyes.

[Jtsummers]

CMMI isn't a process, it's a process model. Or that's what they like to emphasize.

The distinction is this: You can't take the CMMI model and execute on it, it lacks sufficient detail. Superficially, if you read the model and try to execute on it you will end up with Waterfall. What you're supposed to do (and why they're making CMMI 2.0) is map your existing processes (or develop new ones) to the model. That is, if you look at the things required for verification it's not complex: you need test cases, test reports, and some other things. It doesn't have to be heavy weight, point out your test scripts and reporting system (CI/CD platforms all have these) and how you maintain them and train people to use them. Done. But if you're not careful, people will write your process per the CMMI model and it's absolutely junk (witnessed in last job, one of the reasons I left).

CMMI 2.0's problem is that it's written as if Agile (Big-A) is the one true God. But it will almost certainly suffer the same implementation issue, it's not a process but people will try to make it one. As such, the resulting processes they do make will be process theater and hinder work, or at best have no effect but to waste some corporate resources. It does lay out a case, better than the previous CMMI model, for picking and choosing parts of the model to implement and get certified on. So that may help a little bit (less all-or-none attitude).