Edward pointed out the great article by Kevin Matheny, featured in BusinessWeek, on Agile, and our experience on BestBuy Remix.
I'd like to highlight this passage:
Trust is tied closely to how you deal with change. Often, extending trust is hard for businesspeople working on technology projects, because we don’t know how to do the work. We often look to the documentation — requirements, design specifications, and the like — to give us the feeling of control over the outcome. Don’t bother. If you can’t trust your team to deliver, you have the wrong team. Find people you can trust, and then let them do the work. Talk every day, and make sure that the development team has direct access to someone who will be using the product every day after release. For Remix, we’ve never had a formal project plan, never had a requirements-gathering session, never created a requirements document. We chose the right partners, told them what we needed, and got to work. We have control over the outcomes, but we’re not worried about trying to control the details of how we get there.
Of course without trust, any project - "agile" or not - is at risk. But practices typically associated with agile let you go further with trust: everyone is in close communication*, and all levels of the project - from test-driven code written by developers, to regular demos to the client of the latest features - are oriented around fast feedback.
In other words, you the customer trust us in part because what we're doing is visible and tangible to you. If we're going in a direction you didn't intend, or what the team planned a few weeks ago just doesn't seem relevant anymore, we all talk and we correct course.
* for close communication, see Pivotal Tracker
I love to see the metaphor between traditional large construction like building bridges and software. It is so informative and insightful.
First of all, people know EXACTLY how to build a bridge. It has been done many times, and we rarely get it wrong anymore..
However, web software development is different. As Kevin points out, things change on a yearly, or more likely, monthly or weekly, basis. There's no way you can plan your technology far in advance.
Also, there is a fundamental difference in familiarity with technology between traditional large-scale construction and software development. If you are building a bridge or skyscraper, you will want people who are masters of their trade - who know exactly what they are doing, and have done it many times before - this goes for the architect, steel detailer, welder, crane operator, etc.
With software development, on the other hand, being a "master of your trade" has a fundamentally different meaning. If you know in advance exactly what you are doing, and have done it hundreds of times before, you are probably doing something wrong. Yes, you should know general principles, have a deep knowledge of your language of choice, good agile practices, TDD, good OO principles, the HTTP protocol, etc. However, if you are pounding out the gritty details of the code by rote memorization, never making a mistake, then you are far too deep inside your comfort zone.
The "Pragmatic Programmer" goes into some detail on this. The material and per-unit cost for software is zero compared to labor cost. You should have long since written libraries, generators or macros to do that rote work (or chosen frameworks that do most of it for you, like Rails). The problems you encounter should be mostly new ones, ones that you have not encountered before, ones that causing you to think hard, and make mistakes sometimes.
The reason is that this uncertainty, this continual pushing of the envelope, is what makes great software and great programmers. As mentioned in the article, YouTube, Facebook, Myspace, and Google didn't come about because their programmers were doing rote things that they already knew how to do and had already been done thousands of times, according to a project plan written a year in advance. They were finding a niche, doing new things, breaking new ground, thinking hard, making mistakes.
Also, as mentioned in the article, this can be very hard for business and project-manager types to accept - especially in an Agile environment, where Communication and Feedback are king, and there are no secrets. Yes, your developers may be mystified and blocked by the latest problem with the new version of the web framework on the Monday morning project standup. Don't Panic. If they are good developers (and that is the only kind you should have on your team), they will figure it out, or work around it, or meet with you and the rest of the team to figure out a viable alternative that meets cost and schedule constraints.
One main reason Agile works so well is that it embraces and rewards all of these philosophies, and nourishes, attracts, and builds great developers and great teams. I can't say it better than Kevin: "For your next project, try becoming agile. You'll never look back. "
-- Chad