The idea that waterfall and agile paradigms aren't compatible is incorrect in my opinion. They are orthogonal. Waterfall is just a paradigm that people compre

The idea that waterfall and agile paradigms aren't compatible is incorrect in my opinion. They are orthogonal. Waterfall is just a paradigm that people comprehend because it maps to reality: 1. First you have to initiate something and define some sort of scope, otherwise, why are you even here? 2. Then you have to refine your understanding with more design 3. Sooner or later you have to actually build something, otherwise 4. Eventually you will have to deliver and implement it with humans in front of it 5. Someone will have to live with it for a while. That'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't mean that they don't exist in reality. Likewise, agile is a paradigm that developers comprehend because it maps to their reality. 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. I'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's intuitive for most "natural programmers." So while I was taught "waterfall" 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. YMMV, but it has worked great for me for decades.