Agile Development: why small iteration in big projects?

I'm just back from a training about Agile and Scrum and one question made from an attendee was:

"You said it's hard to success in a big project without implementing small iterations; I'm skeptic about it. How do you manage big time line as short-term iterations?"


Think about the Pareto Principle also known as the 80-20 rule that states that 80% of the effect come from the 20% of the causes.
Currently Agile is addressing that development effort should be spent only on the business direction: you need to implement something that is really valuable for the customer. This states a feature driven's approach instead of others where everything starts from a feature, and everything ends when the feature become something potentially shippable.

From the Pareto Principle:
the 20% of features implements the 80% of business

In a Project, big 100 the investment is 100 a the total of returns are 100.

From an economical point of view results are reached and the mission can be thought as accomplished.

Watching it in a different perspective thinking that the 20% of efforts (energy/investment/etc) gives the 80% of benefits, we can think that the effort for getting the 20% is higher than the benefits.

By splitting 100% into five pieces


Different benefits could be gained:
- after 20% of time the 80% of ROI is collected;
- after 20% of time investment could be re-planned in a more flexible way
- after 40% of time the 160% is gained (more than the 100% of time in the previous approach)
- after 100% of time 400% is gained

Finally, product and business grow together iteration over iteration requiring that feature must be ordered having Return Of Investment in mind and having the most important feature for ROI implemented first.

Pareto principle involves a feature oriented iterations in thinking business and in approaching a development strategy.