was born as an overreaction to _X_ and excessive processes, the generation that followed blindly adopted _Y_ as a dogma This happens to everything. It's a patt

was born as an overreaction to _X_ and excessive processes, the generation that followed blindly adopted _Y_ as a dogma This happens to everything. It's a pattern as pervasive as Sturgeon's Law, and may well be related to it. Musical genres come about as a reaction to the excesses of dominant genres, then become a dominant genre themselves. This happens to books, TV shows, movies, video games -- basically everything in modern culture. It even happens in academia and in startups. The reason for this pattern, is that it's often hard to understand the underlying forces and the cost-benefit factors and incentives that shaped _X_ and _Y_. The solution for getting yourself out of the churn of rejecting the old "paradigm" or whatever and adopting the new, is to understand the underlying forces and react directly to them. If you're going to react and deal only with the surfaces of things -- isn't that kind of the definition of the "Cargo Cult" mentality? (also because "agile" is a great marketing word w/ positive meaning, and leaders suffer from FoMo.) At my last company, Agile was the specific response to smaller competitors having quicker iteration cycles. I think it's wholly appropriate response in that case. Also, at one company I interviewed at, it seems that their version of Agile was going towards the "mini-iterated-waterfall" variant, with the manager advocating that every story be broken down to minute-enough detail that estimates would finally be nearly 100% accurate. Are those mistakes or the right move? Time will tell. From the article: What Agile actually is remains vague, even more so than Object Orientation ever was, and that’s no simple feat. Object Orientation is just a vague strategy for code organization. What it actually is depends on the particular techniques and the context of the group actually implementing those. In that, there is a deep parallel to Agile and to religious dogmas and personal philosophy: It's pointless to talk about something so vague, while it's productive to examine specific groups in their success or failure in implementation. In other words, don't confuse guidelines and techniques for silver bullets and magic. Don't comply with _Y_ just so you can label yourself "Y." Look at your structure of cost/benefit and the team's incentives and figure out how guidelines and techniques mesh with those.