It's easier to be critical than correct
If you want to make a name for yourself these days in the blog-o-sphere, there's a simple formula:
- Write something controversial about any topic people might be passionate about
- Wait for sites to link to your article and watch your traffic flow grow by leaps and bounds
By commenting on this article (The Great Pyramid of Agile) from worsethanfailure.com, I'm just adding to #2, but I feel it warrants some attention.
- It may not be possible to build an Egyptian-style pyramid in the way mentioned, particularly with the various rooms and tunnels, but that's a very nitpicky point. Replace 'Egyptian' with 'Mayan' and it is more than possible. That's actually how some of them were built.
- Agile projects don't tend to fail because there "weren't enough good people." They tend to fail because the either (a) the team wasn't really doing agile and/or (b) the team members weren't disciplined enough to stick to the practices. Which leads right into the next point...
- Agile programming is eating less and exercising. It's not a fad diet that promotes a quick fix with little effort.
Eric Jorgensen, who always seems to be able to find exactly the right way to express concepts on our discussion list, takes the credit for the final point and also these statements:
“Waterfall” is a good name for the other practice, because people fall and flow down to it because waterfall requires the least discipline and accountability. Waterfall processes push unpleasant tasks out, both in time and in team space.
If you examine the key differences betwen waterfall and agile, it's easy to see that although agile is conceptually simple, it's much more difficult to do and requires a lot of discipline from each individual in the team. If your team is practicing scrum, it's difficult to fall behind, ignore bugs, or slack off in general. Contrast that to waterfall, where you could code by yourself for weeks at a time with little or no accountability to the quality of what was being written.
Painting agile planning (e.g. Scrum) and development (e.g. TDD, Micro-Pairing) techniques in a "fad" light is not only erroneous, but especially misleading for people who haven't really understood what these methodologies are about. Alex is right in saying that most developers are not "good", by the very definition of the word. However if the developers are writing tests before their code, you're at least guaranteed that what they write will work in those situations. If they return to their code two months later, you are guaranteed they won't break any existing functionality. They may still not be 'good' devevelopers, but their code now has a solid foundation. If the team is using scrum as a planning technique, you're guaranteed that your non-good developers won't be four weeks behind without anyone knowing about it.
I'm not claiming that the various agile methodologies are silver bullets, or a quick-fix-everything approach. They require discipline, they require study, and they often require a complete change of mindset. But to write them off as a 'fad' without truly understanding their purpose would be a mistake.