Heresy 1: Agile is not fast

It may be a heresy, but I will state it:

Agile Development is not faster than waterfall development.

Programmers using Agile techniques are not faster at adding functionality (or requirements, or function points, or any metric you care to use) than developers using waterfall project planning.

As I see it, Agile techniques offer two advantages: consistent levels of quality and the ability to change you mind. With Agile techniques, the 'test before code' practice ensures that you have tests in place and that all new features work, without breaking existing features. The close contact with users and small steps in development (avoiding the large, "think of everything at once and in the beginning" plans of waterfall) lets you decide on the features to add late in development.

Waterfall makes you commit to functionality up front. Typically, the development organization asks the user organization for a list of changes (in order of priority), estimates the effort for each item, estimates available capacity, and then negotiates on the list of items for the release. This list becomes "the commitment" which is then judiciously guarded by the development organization against changes from the user community.

Agile lets you defer "the commitment" and in fact breaks it down into smaller commitments, usually every week or two. The user community can think about new features and postpone the decision to add them. Rather than one big list decided up front, the list starts small and then adds items in small spurts.

But I see nothing in development practices that make developers go faster. (Well, there are benefits from the test-driven practices, but a waterfall-planned project could use test-driven practices for adding features, so there is nothing unique to Agile.) Programmers add code (features, requirements, function points, what-have-you) at the same rate as development.

I believe that Agile Development is perceived as faster than most waterfall projects, from the effects of test-driven development and the ability to change feature sets. I believe that many users are frustrated with the "committed feature set" of waterfall development (probably the day after the commitment) and welcome the time-delayed possibilities of Agile.

But in the end, the number of features added will be about the same.

So it is not actual performance, but perceived performance that makes Agile development seem faster.