A talk by Stephen Taylor describes the differences between traditional, engineering based, software projects, and agile software projects. The analogies are very enlightening. The engineering model is compared to building a bridge. There are two main phases, design, and construction. After construction begins it is expensive if not impossible to change. Software is not like that at all. Specifications and requirements always emerge during the development process and change is inevitable in software projects. If we break up programming into two phases, the design phase continues until the moment the software is delivered. Construction, otherwise known as compilation, is cheap, and can by done a limitless number of times whenever the design changes. This leaves us with the ability to engage the users of the software directly, and collaborate with them to produce the final product. Frequent delivery of finished features provides for constant feedback, and hopefully allows the final product to better meet the users business needs. In the talk, they go even a step farther than most Agile projects. The users actually sit down with the programmer, "break" the problem, or demonstrate the behavior they need changed, and the programmer makes the changes right then, with direct collaboration between the end user of the software and the programmer who can make the changes. The speaker says

From this you can see we have collapsed the stages of analysis, specification, design, coding and testing into a short, uninterrupted dialogue with our user. Communication is high-bandwidth, face to face; feedback is rich and immediate.

The idea of uninterrupted dialogue with the user sounds like the ideal situation, and isn't possible in all projects, but striving towards that goal will improve the results of any software project.