I was a software engineer in the 90s at a small company (15 people) doing simulation development for the UK Ministry of Defence. We had two distinct software development processes, which were waterfall and a form of rapid development known as the Dynamic Software Development Method (DSDM). (I threw away the manuals years ago so can’t give more info).
The company directors came from an aerospace background so had a very strong software quality focus. Many of our contracts specified waterfall and our project artefacts reflected that – user requirements docs, system requirements, architectural design, detailed design, integration test plans, system tests, acceptance tests, etc etc. Coding happened somewhere in the middle. It did work, sort of, in situations where the customers knew what they wanted, and we mutually understood it. Which was quite often the case, for our regular customers on projects that were extending existing systems.
We trialled DSDM for projects where the customer said ‘prototype’ and I liked it. It lacked the onerous agile / scrum boilerplate and IIRC was based around loosely specified timeboxes and relied on having ‘intelligent customers’ who were prepared to be flexible in terms of what they got at the end.
The need for DSDM was motivated by a project that failed badly (not with the MOD) because the customers said ‘here are our requirements for this prototype system, don’t come back until you have finished and tested it’. Needless to say the result wasn’t what they expected, even though all of the requirements had been, on paper, met.
But for any development where specific technical outcomes were necessary (e.g. a maths module), waterfall would usually be used.
Key what I remember was time boxing. And much less religious stance than Agile. But back then it was normal to have different people doing functional designs, technical designs, database design (also in two levels) and business process design of sorts. I guess it took a while for these people to realise they had to be Agile digital transformers.
And I guess it also did not help the DSDM also certified people on the waterfall methodology.
It's still the case in many trades. You don't build a house or a bridge the Agile way for instance.
IMHO Agile got a lot more prevalent because the planning phase became more and more onerous to have any reliability, and management was tired of paying upfront for it. I steady they could get a more regular billing (in particular when dealing with consulting companies) with reports of stuff allegedly shipped, instead of six months of "we're planning very hard, just trust us". Whether the end result matched what they needed/wanted to build being another story.
I know many companies that had an official Waterfall cycle, while actually working on something more granularly shipped with many phases of prototyping. And they didn't move to Agile either, just stopped calling their process anything and went on doing whatever felt right.
Looking at how some houses are built these days, a case could be made for Agile over "do your best, silicone the rest".
If you're building a house, or something bigger, you don't just start nailing lumber together. You have a blueprint. Pretty detailed, and it uses industry-standard terms and markup. Any builder can take it and use it to construct the building. It has the dimensions and specifications for the foundation and all the rooms. It has considered where the rooms are, which walls are load bearing, where the staircases and HVAC and plumbing and electrical runs are, where the windows and doors are, pretty much everything. An engineer has signed off on the overall design as being safe and meeting all the applicable codes. You can order a list of supplies based on this plan and you'll be within a few percent of what you actually use.
Some small changes were allowed. You could change finish details like what style of cabinets or trim or door knobs would be used. But you could not really approach the builder once the framing was complete and say actually I wanted the living room over there and the bedrooms over here and also I want to add a third storey. You also didn't build one bedroom, and then based on that experience extrapolate the design for the next one, and then apply that to building the kitchen, and so on. It was all done up front.
People, especially people who were used to managing physical projects, thought that with the same level of planning, and the same approach to management, the same results could be achieved in software projects.
I can even support an agile process to create waterfall process.
In every single company I have worked, the process always took priority. It's made even worse where you have ISO 9001 compliance where every god damn thing in the company is locked into a "process." Process over people, period. Coporo-managers can't get it out of their head.
When all you have ever done is "the process" it looks perfectly sane. To teams that can produce a POC and basically get to market on their own domain knowledge, it looks ridiculous. Making developers wait for requirements instead of inventing them on the fly is incredibly slow and smothers nearly all innovation.
Why risk making your product look like your convoluted communication and political structures? The entire point of agile was lost on the influx of bodies to the industry.
Form a "skunk works" team and shield them. Make a big show of how their success came despite having zero fucking process. Jira is for maintenance.
How is it my fault? I don’t get to make the decisions and I can’t just change jobs if management doesn’t listen.
Then again, I doubt the company has a reward structure in place that even makes the mental energy worth expending.
If you aren't on the way up, then you are on the way out.
If process (or freedom from process) is important to you, you need to make it a priority when you're interviewing. May depend on what industry you work in, of course, some industries don't have any cowboys.
That said, I like my cowboy jobs with a little bit of process. What's deployed in production should be reflected in source control, but I'm not a stickler for which comes first. A change notification should be posted before production is changed, but if you have separate push and load steps, you can push before you notify (if pushing takes a while, it's good pipelining to use the push time to compose your change notice). Changelogs usually shouldn't be 'bugfixes' or 'latest', but 'fixing' is appropriate for a close in time followup. That's process, even if an ISO compliance officer would lose their mind.