> “And pretty much all the concrete methods sold as “Agile” are processes that have been used successfully somewhere, too, that's usually what motivates documen

> “And pretty much all the concrete methods sold as “Agile” are processes that have been used successfully somewhere, too, that's usually what motivates documenting them.” Agile is a gimmick to sell. That’s what motivates documenting different examples of so-called Agile. It’s similar to the age old scam of sending out mailers to 2^n different sequences of buy / sell advice for n different investment decisions, and then only focusing on the people who received the advice that turned out to be correct in every case. Say that some organization “uses Agile” (whatever that means), but that the engineers deliver a product in spite of the processes that exist “because of Agile” and would have delivered better results with less risk had those processes not existed. In that case, Agile will still be labeled as a success story and trumpeted around as a documented example for consultants to sell, despite Agile having a negative effect. It boils down to a causal inference problem: what would have been delivered in the counterfactual situation of some methodology that did not impose any “Agile” processes? I’m just pointing out that in every implementation of Agile I’ve personally worked in, heard about from friends or read about in HN comments (including this thread), all of the details appear to suggest it really is just this counterfactual problem. Agile has a subtractive, hindering effect on a process of delivering software, and due to engineers doing extra work to overcome Agile and deliver things in spite of it, the end result is that, no thanks to Agile, organizations still ship things and make customer’s happy. Just not as happy as if they did not approach work with Agile process management.