I wish that discussions of Waterfall, "Agile," etc, and systems/software development methodologies would spend more time considering the motivations and rationa

I wish that discussions of Waterfall, "Agile," etc, and systems/software development methodologies would spend more time considering the motivations and rational reasons for why the process approach was created. The practice of systems and software engineering has existed longer than many of us have been professionals, and in many cases longer than many of us have been alive. The "Waterfall" systems (or software) development model was developed to reduce the likelihood and impact of requirements or specification changes over its development lifecycle. Likelihood and impact are elements of "risk," and the process can be seen as part of risk management. Rephrased, the Waterfall development methodology as a process was intended to help ensure that the system being developed (and delivered) was the correct solution (i.e. "valid") for the problems considered, and that the process of getting there would have the best known and acceptable costs. With any instance of a development process, there are risks of: Not getting the requirements or specifications correct (i.e. Failing to understand or solve the actual problem), Completion delays due to time spent on re-design or re-implementation from revisions to requirements or specifications, Completion cost overruns (i.e. delays) due to re-design or re-implementation, etc. The Waterfall process approach was eventually codified into things like MIL-STD-498 (https://en.wikipedia.org/wiki/MIL-STD-498 https://en.wikipedia.org/wiki/MIL-STD-498) for software development. Waterfall is not specific to software development, and some lessons ingrained in the process came from disciplines where the cost of misunderstood requirements, changing requirements, or incorrect specifications are higher. Examples could include the design of a bridge, building, space launch vehicle, network communications systems, etc. In these cases, the further you go into development, the more costly ambiguity and/or errors in understanding the problem become. Unfortunately, as seen with many "processes," strict adherence to process or ritual without understanding or sanity checking what is being practiced against the rationale or purpose for those processes leads to poor outcomes. This is what the authors of the Agile Manifesto were responding to, and ironically the negative pattern of adherence to process without understanding why has replicated itself with modern practice of "agile" -- That is a human behavior and organizational culture problem.