"Agile works because agile has always worked, even before there was some lame-ass marketing phrase called "agile". That means your grand-dad working on the Apollo moon shot probably used some agile techniques, as did guys on the Manhattan project."
OTOH, one problem with "agile" is that it tries to blur the line between itself and anything that was successful. Hence there is never a failed agile project.
"Oh the project failed? that because they didn't do "true" agile."
or the even more insidious, "Oh Toyota has great production processes? That is because they are "agile"
or "The Apollo moon shot went off well? they must have been agile. "
In most cases, such similarity evolves from having overbroad generalizations and/or squinting from various angles till some vague similarity is seen.
"No True Scotsman" is a constantly recurring theme in the various agile mailing lists.
A "methodology" that never fails, and never acknowledges failure (except when practitioners do something that isn't "true agile"), is something that is very suspicious from an engineers pov.
This is not to invalidate your (Daniel's) many good points. Just something to be aware of, especially when dealing with people who vend development methodologies for a living. Most of the agile "gurus" can't code for nuts.
"In most cases, such similarity evolves from having overbroad generalizations and/or squinting from various angles till some vague similarity is seen."
Yes -- you are absolutely correct.
To be specific: agile is incremental, iterative development, emphasizing the social aspect instead of the process measurement aspect of technology development. Agile is also a marketing term and not a branded, concrete system of anything. People have books on agile everything. Because of that, it can best be thought of as an ideal that teams strive to reach.
This means that there is no "pure" agile team. Instead you are looking for agile aspects of a team -- which means that most high-performing teams are going to have some. Agile best practices are simply those practices which most teams will naturally evolve over time. You can pick them up and save yourself some evolution.
"Most of the agile "gurus" can't code for nuts."
A lot of them haven't coded in years, if ever. They're professional teachers, or book writers, or "celebrities". I'm working now with a large corporation as an agile coach (I code regularly) and we've got a couple of guys who are hard-core TDD zealots. Problem is, none of them have coded a real honest-to-god production system in the last five or ten years. One guy has never coded. Yet they're the first ones to tell other teams what they need to do to improve. They read a book or attend a seminar (usually by some other guy who hasn't coded in years) and suddenly they know what everybody else should be doing. That's not saying that TDD won't work -- it's saying that to help a team you really need to be actively working on a team and not be a wonk. I remain dubious of TDD, but that's me.
Beware of well meaning teachers and non-hackers who start getting the agile religion.
OTOH, one problem with "agile" is that it tries to blur the line between itself and anything that was successful. Hence there is never a failed agile project.
"Oh the project failed? that because they didn't do "true" agile."
or the even more insidious, "Oh Toyota has great production processes? That is because they are "agile"
or "The Apollo moon shot went off well? they must have been agile. "
In most cases, such similarity evolves from having overbroad generalizations and/or squinting from various angles till some vague similarity is seen.
"No True Scotsman" is a constantly recurring theme in the various agile mailing lists.
A "methodology" that never fails, and never acknowledges failure (except when practitioners do something that isn't "true agile"), is something that is very suspicious from an engineers pov.
This is not to invalidate your (Daniel's) many good points. Just something to be aware of, especially when dealing with people who vend development methodologies for a living. Most of the agile "gurus" can't code for nuts.