AgileSoftwareDevelopment means delivering the value the customer desires as rapidly as possible and continuing to do so over time.
Value because it doesn't matter how fast you develop the software if it does the wrong thing. We can be really fast if we stop now, but does that produce the desired system? Value means that what we produce is driven by what the Customer wants. Value also means that what we produce generates correct results. Broken software produces little value.
Rapidly means that we (to paraphrase Einstein) go as fast as possible but no faster. Pushing for speed at all costs produces mistakes. Remember that "value" thing mentioned above? Pushing for speed at all costs also tends to produce behavior that hides problems. This behavior breeds failure. If a given date is important, it is better to know the actual progress and to prune "value" explicitly than to let chance choose for you.
In the book Rapid Development (1556159005), Steve McConnell spends the first five chapters talking about how to correctly create software. These chapters are more valuable than all the remaining ones on how to rapidly create software.
Continuing to produce value as rapidly as possible for the long haul is the real need of businesses. While software projects are often proposed as a one-shot campaign, that's rarely what's really wanted. Software is too expensive to build and throw away, starting from scratch each time. You'll want to grow the software's capabilities, following whatever changes in direction that the business makes.
Martin Fowler has a good, brief [http://www.martinfowler.com/articles/newMethodology.html overview of lightweight methodologies], including XP.
Jim Coplien [http://blog.qualityaspect.com/2006/06/07/the-hijacking-of-the-word-agile/#comment-661 comments] about the historical roots of Agile development. "What Ive found intriguing lately is that a rash of adaptive projects started appearing around 1991, at about the time the Org Patterns research started. ... I like to think that the QPW article was a catalyst...that helped give visibility to some of those ideas that even then were tried and true (I think Tom DeMarco had said much about pair programming years earlier; unit testing was old hat; etc., etc.)."
[http://groups.yahoo.com/group/extremeprogramming/message/95236 Phlip's dissertation] on Business Value of Agile Development.
[http://hbsworkingknowledge.hbs.edu/item.jhtml?id=4318&t=leadership Harvard Business School article] on the advantages of teamwork over individual brilliance.
[http://www.newyorker.com/critics/books/?020325crbo_books book review] of The Myth of the Paperless Office, by two social scientists, Abigail Sellen and Richard Harper. [0262194643] This review goes into some of the details about why using paper (think index cards) is a good match for cognitive behavior.
[http://groups.yahoo.com/group/extremeprogramming/message/95559 Charlie Poole's excellent method] of circumventing resistance to the simple index card.
[http://groups.yahoo.com/group/extremeprogramming/message/95504 Dale Emery's description] of understanding why someone would prefer a spreadsheet for planning over index cards.
[http://www.poppendieck.com/pdfs/Optional_Scope_Project.pdf PDF of Optional Scope Project], by Marina Morgagni & Piergiuliano Bossi of Quinary SpA
Many people take a cursory look at Agile Software Development and jump to some ErroneousBeliefsAboutAgileDevelopment. I'd like to dispell those beliefs.