First of all: Some people probably know all about agile. If I asked them what Agile Development was, they’d be all over me about “people over practices” , scrum, Extreme Programming, the Agile Manifesto and a “mechanism for social change”  in a heartbeat, until I asked them to stop.
This is not for them.
In my case, however, I found an interesting and infuriating conundrum. When I Googled agile development, I found all sorts of articles about agile, but nothing that explained what it was. And even more frustrating, there were plenty of links that said “Click here to learn what agile is!” that would inevitably explain that Agile is a new method of development, Agile is about working together as a team, Agile is happiness and friendship.
If you have somehow read through billions of blog articles and well-written essays only to miss the point again and again, this is for you.
When people describe Agile, some things clearly stand out. Tests are mentioned again and again. Short development cycles are always mentioned. The naysayers call it “cowboy coding.”Agile Development is about exploiting our ability to change the product when it is already in the process of being built.
Take a traditional example of “waterfall” design.
Large structures are extreme examples of waterfall. They are planned out in the beginning from bottom to top, because there are absolutely no second chances. If it crashes once, it’s done, as is the architect’s funding and probably his or her career.
This has never been quite as true with retail and web software. A typo in a piece of code is generally more repairable than its equivalent in architecture. This is especially true in web applications, where you don’t even have to release a patch to everyone who bought the product!
What has been true, however, is that the design and architecture of software get harder and harder to change the further you go along. If you build a broken library in the beginning, and try to change it months later, you’ll be faced with mountains of code based on that broken library’s design.
Because of this problem, the best software projects were the ones that were rigid, defined by a few (or one) architects. If you didn’t have a planner who knew where everything went, it would be impossible to maintain. It is a well known adage that every mistake made in the requirements phase is hundreds of times as costly to fix during implementation. 
Why was there no agile in the 60s?
What makes agile possible is our ability to change the code on the fly. Refactoring was an important part of this transformation, as was object oriented development, and many other developments that increased the encapsulation and separation of said code. This is where testing comes in; by having unit tests that guarantee that all of your code functions, it makes it much easier to make changes safely.
These practices are the ones that separate agile from default no-organization development; without the ability to rewrite software on the fly at a minimal cost, it would be impossible to use methods that depended on requirement flexibility and the ability to adapt to new requirements.
Is that all there is to Agile?
Agile evangelists mention a number of other principles, however, that don’t seem to directly relate to this low cost of change philosophy. Does agile really demand a higher level of team work and individualism then previous methods?
Maybe, maybe not. But it can be said that, to a certain extent, Agile enables those sorts of behaviors to occur. The waterfall method  of software architecture values coherence and organization, because it is a scarce commodity; the entropy of a software system always goes up, never down.
When it is possible to repair and alter architecture quickly, more people can become architects.
More on this someday.
More reading: http://www.martinfowler.com/articles/designDead.html; Photo credits: wikipedia