The Waterfall methodology was a historic accident and they knew it
I work for a corporation that has worshipped Waterfall for many decades. We are now in the middle of a years-long large scale “switch” to Agile, which is a vast cultural change.<p>My observation is that Agile is all about software development, tuned for software development, and for the benefit of software developers and the customers of software.<p>Obvious, right?<p>What’s not so obvious is that a surprisingly small portion of what people think of as a software project is actually about software development.<p>Interacting with 3rd parties, writing contracts, hiring developers, planning how your project interacts with other projects and the wider organization, responding to regulations and external enquiries, managing the demand for certainty from stakeholders, obtaining funding, maintaining financial control...<p>These are the issues that real software projects have to deal with, and Agile is silent (if not actively hostile) on how you should deal with them.<p>If your project is truly <i>just</i> about developing software, sure, be Agile about it. But it’s not through ignorance that people “fall” back to Waterfall in the face of real world constraints.