If you accept that agile is aimed primarily at programming, and it is basically XP without the pair programming, then it is completely appropriate and any failings are people trying to apply too much process to it.
make a list of everything that is suppossed to be in the product with estimated costs.
prioritise the list to the things that people want to see first
pick items from the list to attempt to get done in the two week release cycle
people collaborate to ensure the best design and testing is identified
ensure everyting is covered by automated testing so there is not a huge testing effort at the end and therefore unknown levels of work resulting from problems found
merge work in to the release often so as not to encounter issues at the end of the release cycle when unknown levels of work could result
regularly meet briefly to check everything is on track and how to resolve any issues that have arisen
release
review what and how much was done to improve estimates of the amount of work that can be done in the next release cycle
review the released product to ensure everything is going the right way
review the priority of items on the outstanding list, allowing new items for amendment of the released product if required with the acceptance by the business of the costs involved
finally deliver a product that exactly meets what the business requires
Seems to make sense and the ideas are all based on a pragmatic review of past project failures and what works.
It realises that requirements change along he way as people get to see and play with what they thought they wanted.
It’s a JFDI type of process, any extra process and formalisation added is the result of ‘consultants’ trying to make money off of it.
A grade people will make the process work and deliver, B grade people will just sit back and moan about it…