Many times you and I have heard about advantages of Agile development techniques and drawbacks of traditional “hard” techniques like RUP, MSF and so on. I think, sometimes we are mixing them up.
A lot of software engineers, project architects and even PMs prefer the Agile approach because of the anarchy it allows in the outsourcing development. I mean the absence of specifications (even when they are really needed), merge of project roles and responsibilities (when no one can say who is responsible for low quality level and specification), and the sacred belief in users’ stories without any additional analysis of business goals.
The situation can become worse if a customer hasn’t got a clear vision what he wants to get at the end of the project, if the requirements weren’t completely described and verified by him and finally they were implemented according to the developers’ point of view. Most probably the client’s expectations will not be satisfied, and it will lead to hours of overtime, release date shifting and other symptoms of an unsuccessful project.
In addition, unskilled key project persons frequently use this fashionable term to clear themselves when they fail, the project deadline is out-of-date and the customer is not satisfied. They say “We create software using modern flexible approaches, we don’t need all these hundreds of specifications and process descriptions! This is Agile, baby, so relax!”, but usually they forget one important thing.
Agile practice is not the universal magic wand that allows you to make any project no matter if it’s low-sized or estimated in 10 thousand man*days, with minimum of documentation, absence of project roadmap, detailed architecture and so on. Of course, it could be so in small/medium projects and on the assumption of all project-members already have agile experience and the Project Manager keeps all working activities and plans in his head. But you have to keep in mind that it’s rather risky to rely on this.
I strongly believe that Agile development process should be used only by highly-experienced web developers – because they already know the weak points of this methodology and they will not addle with the seeming simplicity and easiness of this approach.