Craig,

Thanks for the compliment?

My view is that Agile is better than analysis up front when you don't want to do analysis up front. This is not meant to be a joke: my understanding of Agile is that it is lots of small changes that sum up to one big change. The advantage? Any cock-ups on the way can be fixed in the next release. The premise then is use Agile as you will get it wrong but with Agile you can fix it next release. The important thing for me here is that premise: you will get it wrong.

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.

Responses:

Agile: we might as well accept that then and make the impact of those errors as small as possible with lots of little releases.

(some kind - any kind really - of) Structured Analysis: we better make sure we get the analysis right.

There are pros and cons to each. No-one denies (as far as I know) that in the long run take 2 successful projects and the one done in Agile is more expensive (minimised economies of scale as compared to step change projects).

So, Agile is good for those who don't want to do analysis up front.

How can you change something when you haven't defined what you are changing (i.e. done the as-is) and what you are going to change it to (i.e. defined the to-be) and thus defined the change. Answer: trial and error, lots of little changes. You zig-zag to the final destination.

That's not say that loading the analysis up front doesn't have issues (analysis paralysis anyone?).

Bottom line: somehow, you have to do the analysis in a rigourous way - and I don't care what method or approach is used so long as the analysis follows a chain of reasoning that can justify every component of the change. Otherwise it is guessing and sometimes you get lucky but most times you don't and thems the odds.

Guy

Hi Saurabh,

Thanks for your comments which I would like to respond to as Agile is a popular approach right now.

Your comment that Agile is useful when you don't want to wait for half a year or a year could be seen to imply that doing analysis will take that long. Of course, that may or may not be the case: doing analysis takes as long as it takes to do the job properly, just like Agile does. Certainly doing analysis does not invariably result in such a delay.

Your comment that “agile is actually deployed in situation where practically the requirements can be changing every day and every week” makes me wonder how long any solution developed will last – whether or not it is developed using Agile. If the requirements are changing so rapidly so is the required solution…and as an analyst I wonder why the requirements change so rapidly: is it because the real requirements really are that volatile (in which case developing any solution seems too short lived to be useful - have payback - unless you develop a solution that has as requirements the ability to change rapidly in response to changing business circumstances – careful thinking needed here to avoid huge costs!) or because the requirements are not really fit for purpose and as the thinking develops amongst the generators of the requirements, so do the requirements change.

Your comment that "you may have some business requirements, which were quite complex in nature and a wrong step towards them could bring down the whole project. so why wait for a full release cycle of a year, and instead break requirements into smaller chunks and using agile deploy them so that you dont loose time and know exactly where you are heading into." was intriguing: here I think you are suggesting that there are critical complex business requirements that the business can't wait for so you break them in to smaller chunks - but how can that be done without doing the analysis first? And if there isn’t the as-is part of that analysis, Agile or not, how can it be known know what is being changed? And if there is no to-be part of that analysis, how can it be known what it is being changed to? And if it is not known what is being changed or what to, how can it be broken down in any meaningful way?

In practice, a small change CAN be made and anything that goes wrong as a result is likely to be a small fix. This is the trial and error approach I have written about – and while it is not the most direct or cheapest way to make change, it is the least risky (in the short term but not long term) because it is a set of small changes. It's not the least risky in the long term because of the risk that not knowing what the start or end states should be  leads to the risk that after 100 changes 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.

And this may be where Agile will – in the longer term – have to be modified or abandoned. These longer term risks will materialize but they take time to build up and then – I suspect – like so many other approaches (RAD, JAD, Lean, Extreme anyone?) it will go out of fashion to be replaced by another approach offering the holy grail of making changes without the effort of doing the analysis of requirements.

Guy

Guy,

I have some comments and a question for you. 

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.)

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. 

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

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.

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.

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.

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.

Craig