agilists miss the point
What a lot of postmodern nonsense agilism is. You must reject all process except of course the agile process. You must use the core values or you are not agile. If you use the core values and fail, then you are not agile *enough*. This is precisely the same thinking as belief in magic. Cast the spell, just like in the book. If it doesn't work, then you didn't do it right, because it's magic and we already believe in magic. If it does work that proves magic works!
Agilists make straw man arguments about plan-driven methods that are impossibly rigid, then say "see, agile is better." Agilists blame the developer for failure, because it cannot be a weakness in the agile method. Agilists discourage questions about the efficacy of the agile method, and questions about the underlying assumptions of inability to plan effectively.
And here's a little secret just between you and me. Agile doesn't work unless you are doing just the right kind of development. Yeah a lot of agile's core methods work. They were invented by those bacdward, hoary old plan-driven folks, and put to good use when many agilists were in kindergarten. And yeah, agile isn't too bad a choice when you are replacing no-process-at-all, when your staff isn't well trained or experienced, when the project isn't too big, and when you don't face any deadlines. But practically any process at all will work under those very favorable conditions.
Not every software developer enjoys the mental effort of planning and scheduling. And virtually none like being held accountable to a plan or schedule. Agile is the feel-good solution to this problem. But is it the *best* solution?
Yeah, I know, optimizing and planning are part of the same school of philosophical thought, an old school that has been overthrown by glorious new paradigms of thought proclaimed by, amongst others, agilists. Maybe.
Here's a prediction; in 20 years we'll see software development that looks kinda agile, but with requirements capture as a separate step, supported by tools that aren't routinely used yet. Way more emphasis on different ways of testing, and on measuring and improving a process that takes account of differences between teams. Schedules will be back in fashion, but supported by newer notions of how to schedule. And there will be a proclaimation that this method is the *old* way of doing things, and there will be a *new* way supported by a new batch of young impatient consultants, eager to grow rich on your money.