The problem with agile

The problem with agile is that it is most of the time used as a methodology smoke-screen for having no methodology. It works fine if you have a complete specification first and a have a design for the system worked out first. Then you can deliver frequent iterations to make sure that what is in the specification and what has been designed is actually what the customer wants (it frequently isn't).

The notion that you can use "agile" development methodology to avoid a thorough requirements analysis, detailed specification gathering, and working out a reasonably detailed design is laughable.

Perceptions clearly wrong

a) Agile is not a no-methodology system. It is highly methodical with a strong requirement for many things which are there to ensure efficient working.

b) It has a requirement for a person to own and maintain a requirements list (specification), while this is open to change just as the world is, but it has to exist and if the person in charge of this is no use then you are in no worse a position than with a useless specification in a standard waterfall process.

c) It doesn't require a design for the system to be created first BUT it doesn't say you shouldn't do some design. The amount required is going to depend on the competence of the engineers. I have seen many designs for products followed through and the product dropped at the very last moment after a lot of work because the product is no longer competitive or relevant to the market. Under a well managed agile project a decision would have been taken to change the specification, this may have led to a redesign - or even possibly to the scrapping of the project long before the 'end date' and the realisation the team had spent months or years on something worthless.

d) As with ANY project someone needs to create the requirements (in 'scrum terms' the user stories), that these might change does not negate the requirement to create them in the first place. One thing that many people (including the fans of agile) fail to note is that a company needs to look at the project - its aims, the requirements it will create, the cost and timescale of doing this versus the benefits BEFORE the project enters the (usually more) expensive development phase. With agile the person in charge of the requirements can change them (just as change requests can change a waterfall project), the company needs to ensure that the requirements owner is kept within a reasonable cost and within the bounds of what is the over all aim. This is exactly the same as required with any other project methodology. Agile does NOT get rid of this basic requirement.

e) And as for shipping crap code for users to test there is no more chance of that than you get with waterfall methodologies. The team tests as it develops and the internal releases are of at least as good a quality as any alpha or beta release from waterfall. The decision to release the developed product is made by the guy who owns the product - as it is with a waterfall project. What many fail to realise is that with agile there is nothing against running a period of test and fix at the end as you do with waterfall. In fact, just as it is with waterfall this period is needed.

f) The engineers are recruited to be intelligent enough to develop your product, so trust them to be able to work out the how, who and when of this.

There are of course numerous companies implementing agile in terrible ways and abusing the principles.