We'll respond shortly.
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