I am in agreement with most of your response. I want to follow up on a couple of points. > "I'm not sure why you think this is relevant to the post" Well, it'

I am in agreement with most of your response. I want to follow up on a couple of points. > "I'm not sure why you think this is relevant to the post" Well, it's not. It's a response to the comment concerning "practices that were commonly and harmfully adopted". I want to soften that from "commonly" to "sometimes". However, it's hard for me to really justify that. Agile comes out of government/enterprise. That's clear from the manifesto, which refers to "contract negotiation", and where the principles refer to "the customer's competitive advantage". Neither are really relevant to, say, the end-user games that I mentioned earlier, or to software one writes for oneself for fun. Within government/enterprise organizations then and now, I agree that many use various modified versions of waterfall and, as you say, straight-jacketed methodologies. What I don't know is, how many software projects in the 1990s were using heavy-weight processes, vs. ones which would be now called agile? (Or a third category of none-of-the-above?) For example, in the mid-1990s I worked for an academic research group of ~20 people, and we distributed the source and binaries for free so I also did some support for external users. There was no emphasis on processes and tools, nor comprehensive documentation, nor contract negotiation. Most users were within a few tens of meters from me, there was close collaboration, and I could do several build/releases per day if needed. According to the manifesto, I was agile, yes? But that approach was also not uncommon for other research or in-house software, and it wasn't much different from the software development process at the startup I joined in Palo Alto a couple of years later (during the dot-com era), or the places I worked at or consulted at since then, all doing scientific research support software development. By count, and perhaps even by budget, were there more of these small-scale agile-like projects than there were heavy-weight government/enterprise projects? If so, then waterfall would have been relatively uncommon in practice. > "Asserting that waterfall models are a pure strawman that exist only to sell "agile" models is false as a matter of readily verifiable fact." I do not argue that waterfall is a pure strawman, rather that many agile proponents present the dichotomous choice of "waterfall" vs. "agile", and use that comparison to market an alternative, agile method as the alternative method. (I like your Boomers/Gen.X/ Millennials example - slackers represent!) This isn't a strawman, but ... I don't have a word for it. Choosing the weakest opponent, propping it up by always talking about it, showing you're approach is better, than concluding you are best. Laurent Bossavit has written much about this, but I couldn't find the one I remember reading before, so I'll quote https://www.infoq.com/articles/bossavit-agile-ten-years-on/ https://www.infoq.com/articles/bossavit-agile-ten-years-on/ > The most dangerous distortion of all is the notion, sadly prevalent today, that Agile consists of a handful of competing "brands" of processes: Scrum versus Extreme Programming versus Lean or Kanban. In the interest of pushing this or that brand, the interesting details of our young history are papered over.