Difference between iterative and incremental development and a bit for agile

A really useful perspective on iterative and incremental development from JanBlog

"Do you sometimes also have problem to make clear distinction between iterative and incremental development? What if you should explain difference to customer or friend?

Hopefully these two pictures taken from Don’t know what I want, but I know how to get it will help you understand it.

When you work incrementally you are adding piece by piece but expect that each piece if fully finished. One picture is worth of thousands words :)
When you work iteratively you create rough product or product piece in one iteration, then review it and improve it in next iteration and so on until its finished. One picture is worth of thousands words :)
So is Scrum incremental or iterative?

It is iterative by the definition as we are running sprints. We are improving application iteration after iteration.

But I believe it is also incremental because user stories finished in sprint should be of shippable quality and therefore we should not return to them in next iterations.

So Scrum is iterative incremental process.

Is this your opinion too?"

I currently thinking scrum/agile must draw on a iterative incremental process.

This links with a a recently read question asked to Alan Cooper on
asking “Is incremental design the wave of the future, or just a flash in the pan?”

"As agile methods take over the programming world (and they will), EVERYONE else will adjust accordingly. The old paradigm of everyone hunkering down and protecting their turf from everyone else is what gave rise to the "traditional cycle" (which is, by the way, uniquely ill-suited to software construction and design).

The new (agile) paradigm isn't at all defined yet, but it characteristically includes a) Generation Y programmers; b) a refreshing belief in the potential for change; c) the understanding that satisfying human users requires special efforts and probably special skills; d) a belief that software should be built in continuous increments; e) a corresponding belief that everything else in the world relating to software would benefit from such continuous increments; f) that building software is a team endeavor; and g) that nobody has solved these problems before.

It's very reminiscent of the way I felt in 1976. At that time, all computers were multi-million-dollar affairs, residing in specialized corporate bunkers, owned only by large corporations, and used to perform operational business functions. I, on the other hand, had just purchased my first computer.

It was a 1MHz, 8-bit microcomputer with 8" floppy drives and 64K of memory. All of the then-current assumptions about software development, creation and use were marked for death as we Boomer Generation programmers began to invert the dominant paradigm.

Within 15 years, we had utterly changed every aspect of software and computing, and today's agile, Web 2.0, open source, Gen Y programmers will do the same, only faster.

Interestingly, the changes we wrought were almost all bottom-up. The only influence large corporations had on the great microcomputer software revolution were to obfuscate and delay it. And, of course, the reason why we study history is so that we can chuckle at the irony of its inevitable repetition. Today's changes are also coming up from the bottom, and big companies are doing little to help and much to hinder.

Thanks,
Alan"

Is there more scope now for understanding and demonstrating how the agile process should be without such hinder with the understanding how it can be used with UCD ?