The idea that waterfall and agile paradigms aren&#x27;t compatible is incorrect in my opinion.  They are orthogonal.<p>Waterfall is just a paradigm that people comprehend because it maps to reality:<p>1. First you have to initiate something and define some sort of scope, otherwise, why are you even here?<p>2. Then you have to refine your understanding with more design<p>3. Sooner or later you have to actually build something, otherwise<p>4. Eventually you will have to deliver and implement it with humans in front of it<p>5. Someone will have to live with it for a while.<p>That&#x27;s reality, on any project.  How you choose to step through these phases - rigidly or fluidly, linearly or spiral-y, or linearly but recursively, doesn&#x27;t mean that they don&#x27;t exist in reality.<p>Likewise, agile is a paradigm that developers comprehend because it maps to their reality.<p>If you build software for customers, how you do it is your business, but you will be best off if you can frame it in a way that makes sense to the customer.  Especially if that customer is the Department of Defense or some other customer who will demand deliverables on a timeline.<p>I&#x27;ve been building software professionally since the 1990s.  As someone who learned programming at a young age, prototyping is my natural way of problem solving, and I think it&#x27;s intuitive for most &quot;natural programmers.&quot;  So while I was taught &quot;waterfall&quot; in school and have always used it with my customers, I have always built by prototyping.  My customers love it, because on the surface they see a software design process that they expect, and I can communicate my progress with pretty Gantt charts and familiar terminology.<p>YMMV, but it has worked great for me for decades.