Tony,

I agree with you: my understanding of Agile is that it is based on a premise that the analysis of requirements will be inadequate so minimise the resulting damage by doing lots of little iterations so that you can fix the cock-ups of the previous release in the next one.

The real world is often on the side of the Agileists in that the analysis of requirements often is inadequate because all the high-impact-if-you-get-it-wrong analysis is done up front of a project and so is often the second casualty when timescales are tight (the first being testing). The 'strategy' of tight timescales is limit the amount of work in the area where most errors come from (according to Standish group chaos reports) and whose errors cost most to fix. 

Then, when that project (predictably) goes wrong, a case can be made for saying "lets do lots of little projects often - we can cut down on the analysis cos we aren't doing much and we can fix anything wrong in the next release anyway". Its a sort of trial and error...with the relatively high costs of Agile (lots of little changes lose the economies of scale of bigger changes) and change fatigue for users.

Agile has a place but it is not a cure-all - its just the latest in a long long line of approaches that 'fix' all the problems projects face when they don't invest enough in analysis. Here's the thing, whatever the approach or the method, analysis of objectives, requirements, process and data will need to be done (formally or not) and you can either plan to do it in a rigourous manner or just wait for it to pop up as it will when the solution is effectively guessed at by not doing enough analysis of requirements.

An anology: a change is a journey. You can plan out your route first and go straight to your destination or you can guess the direction, travel a short way in that direction, check your compass, adjust your course and zig-zag your way to the destination.

Which is best? Mostly I plan my journeys although sometimes I like to amble along as well in no particular direction when I have nothing better to do!

Guy

Tony,

Project Expiditer? Is this a new job title? Or how about Project Fixer?

The other thing is this: I just checked and "Project Expiditer" gets 1980 google hits! We're too late! Even "Project Fixer" is sloshing around (762 hits). Reminds me of the time I was joking that you could develop a new BA jargon generator: you start by selecting your approach and method (I gave the example Agile Six Sigma and called this new BA system ASS) and then for each of the standard components for analysis (drivers, objectives, requirements, processes, data etc) you could generate new jargon (ASS-drivers, etc) - a powerful quick start-up piece of jargon for ASS was kick-ASS.

Then I googled it and Agile Six Sigma exists!

I'm hoping it gives as-is modeling 8% time allocation being focused on TQM-ing existing processes...

Guy