There’s an interesting post over at Clarety Consulting today that seems to be guilty of spreading FUD about Agile development. In the post the author goes through several “real-world” experiences with Agile techniques and explains why the projects failed because of Agile. The problem with the article, in my mind, is that these failures have nothing at all to do with Agile. All of these projects would have had the same problems regardless of development methodology. The main crux of his argument seems to be that Agile creates a chaotic development environment where the developers rule and everyone else is at their mercy, but I think that has much more to do with the developers you hire and less to do with the methodology they use. He talks about the senior developers being dictators and taking all the good work for themselves, but that goes directly against one of the key tenets of Agile (i.e. no code ownership). It seems to me that the author has had some bad projects, with some bad developers, that were done with Agile techniques and he is choosing to place the blame on Agile when it really belongs squarely on the shoulders of the team itself.

That being said, I do think that the experiences he has run up against are probably pretty common and the Agile community is partly to blame. There are too many in this community that believe that Agile is some panacea that will solve all your problems if you do it “right.” The reality is that development is hard and there is no silver-bullet. Agile can help precisely because it is meant to be flexible, but no one will get that if the community turns into a bunch of raving know-it-alls whose only response to problems that teams encounter is “you’re not doing it right.” There is no one way to do Agile development; it needs to be tailored to the environment you are using it in, just like every other methodology does.