Craig,
I have some comments on your comments and an answer to your question (but you may not like it!):
1. An Agile development approach probably has the same amount of analysis over the life of the project. It's just done iteratively, like the development. As a result there is the opportunity to correct mistakes with less cost (and you know the cost of quality over time story.)
GB: An Agile development does MORE analysis over the life time of the whole change project as for each release it will have to come up with rationale for each chunk in terms of smart objectives (no smart objectives why bother doing the change?), requirements that deliver those smart objectives, process and data requirements that enable those requirements, non-functional requirements defining the security, performance, volumetrics etc of the processes and data, impact analysis of the solution on the business, analysis of cutover processes and procedures, analysis of test cases to prove that UAT tests that requirements are delivered.
So if you look at the complete change then it is more costly in terms of analysis. And I repeat an earlier point: Where do most faults come from? Analysis (according to Standish Group Chaos reports). Which cost most to fix? Analysis errors because they incur the most rework as they are the first stages of the project. What do projects spend least time on? Analysis.
Summary: Project expend least time on the area where most errors occur and that cost most to fix.
The Agile response: we might as well accept that then and make the impact of those errors as small as possible with lots of little releases.
I would prefer to fix the problem at source and do the analysis correctly.
2. Agile uses working software as one way of validating requirements, which these days can be done relativiely quickly (especially with scrum) and with good effect in relation to documents. You yourself would have experience with prototypes - it's a variation on this theme.
GB: Prototypes for me are a tool to validate and confirm requirements, nothing more, and are always paper based mock-ups. If all Agile does is provide a method for validating the products of up front analysis I am a happy bunny. I suspect it isn't and so I am not hopping for joy...
3. Project resourcing and burn rates mean that often a project team is established before the scope and requirements afre fully fleshed out - so rightly or wrongly, it's better to have the dev team working than sitting around reading incomplete docs
GB: As Tony put it: “To quote Einstien: Never confuse motion with action.” To quote me: “Project expend least time on the area where most errors occur and that cost most to fix.
The Agile response: we might as well accept that then and make the impact of those errors as small as possible with lots of little releases.
I would prefer to fix the problem at source and do the analysis correctly.”
4. Analysis up front without the dev team in place and woking means that you are not in a rush to market, which is true say in some government areas, but in most product and service industries is not the case. Note the agile maxim of extract value early.
GB: I’ll see your maxim and raise with “more speed less haste” and “act in haste, regret at leisure” and “there is never enough time to do the analysis and always more than enough time to cast blame when things go wrong”.
5. Requirements churn does hapen on lengthy project becasue in most cases the environment is changeing - legislation, competitive forces, technology etc are always evolving. It is getting rarer and rarer to find stable environments in which requirements stay relevant anc complete for extended periods.
GB: That kind of predictable churn good – requirements changing on a daily basis, bad. There is a reason for that sort of volatility and that reason should be incorporated in to the analysis of requirements. Whatever, requirements churn is not a rationale for acting without analysis, in fact it makes the case for more analysis in terms of impact.
I agree that some up front analysis is required - eg understanding the problem domain, business model and top level business process, but beyond that I am very comforable with building and correcting as you go.
GB: Please don’t ever be involved the analysis of requirements for a plane I fly in – but you should get heavily involved in the Death Star project you proposed as I am sure Darth and the Emperor would be happy with a trial and error approach!
Now, my question;
You stated earlier that all things being equal an agile project will spend more than a planned up front project. Can you share your source for this comment? If you do I am goin to bait the agile message groups with it.
GB: See above: I analysed it and thought it through. I don’t have any official stats but give me 5 years and when the Next Big Thing comes along, it will provide the official stats…Compare the same project that is developed and implemented two different ways: waterfall and Agile: the basic problem with Agile is economies of scale: you have to repeat all the project steps (project set up, analysis of objectives and requirements, solution design, development, coding, testing, procedure redesign, training plans, cutover procedures, data migration, etc etc etc). Agile has advantages as it minimises risks on a chunk by chunk basis but as with everything there is a price to pay, and that price is time, effort and money, and increased risk! The risk increases over time because of the risk that after 100 small changes for one big project it will be necessary to go back to the first and correct something that didn't come out as an error until the 100th change - because the end to end analysis hadn't been done – and now changes 2 to 99 have to be redone to cater for the new change.
Bottom line: Agile has uses and so does waterfall and so do JAD, RAD, Lean, Extreme and any other 101 methods and approaches. However, none of them have (to my satisfaction) got rid of the need to do up front analysis...
Guy