[devonkim]

The advantage I do see for Agile is in shops where management is justified in their belief that developers are being over-cautious as well as too relaxed - this is exactly the atmosphere in many low-throughout software organizations I’ve seen in lots of old, non-software companies. If management is fine with lowering quality in favor of more shinies, Agile is pretty alright - it is Worse is Better codified and institutionalized. If the codebase is so bad it is impeding your ability to deliver business results, you do have justification, but time boxing efforts is important to avoid going down rabbit holes of endless refactoring.

I think most of the developers that are hating Agile are probably more disgruntled with their organizations and their culture (usually hostile to high quality engineering in most places fundamentally) than Agile itself. In a way, I think Agile (similar to a lot of automation efforts in infrastructure / IT processes I’ve worked on) simply brings out the true nature and culture of who is driving, who pretends to drive, and where things are falling apart in team dynamics. The software is usually a casualty of bad dynamics is the implication, not bad team members, but we all know this is not true.

I think the #1 thing that is missed is that the implementing team should have more control over what they work on. Someone writing a bunch of tickets and pointing them out alone reduces team ownership / responsibility and is pretty much how traditional Taylorist work models are built. Agile is fundamentally much more in line with Deming’s ideas giving much more control to the implementors and that is antithetical to at least 80%+ of businesses in the West and probably Asia too.