One day they called and the GM said they would buy thousands of copies if we added a special chart type (Radar) so we figured out what that was, built a basic implementation and sent it via FedEx in a couple of days so they could demo it. That wasn't unusual at all. What made such dynamic development possible was that we did full application testing every day, between our tester and the publisher's. By the time we got to a "beta" state, most everything was working; we rarely had something that wasn't almost ready to ship. Maybe the team was special and made it work, I don't know. Deltagraph was similar in size to Excel but our team was a tenth of the size.
Today, organizations fear putting too much into the hands of people and would rather have fairly rigid structure and process to guide development. Scrum and kanban really don't feel very agile to me at all, given my early experience—I guess lean is closer. I think given a good team and technical leadership, you can build processes that makes development work well without following some canned recipe. Of course, all my teams were fewer than ten, clearly the larger the team the less likely a self organizing process can work. I don't think of today's agile processes (Scrum, kanban, Extreme Programming, or even lean) are the end stage of software development.
I feel lucky to have experienced a decade of pure agility long before it got a name but I know we weren't the only ones. As time goes by I hope people don't get stuck thinking of agile as a limited set of rigid structures. The Agile Manifesto is such a marvelously simple philosophy, but people love turning everything in a recipe or silver bullet. Agile is supposed to be agile, not a yellow brick road; you have to follow and keep within the lines.
Texas-based programmer Andrew Wulf runs TheCodist blog, is the lead iOS programmer for Travelocity, and is the owner of Idle Diversions, an iOS game company.