An issue I sometimes come across is that clients aren’t always able to get the level of transparency from the developer they need in order for Agile processes to work as designed. It’s not always easy, for instance, to pin a developer and his team down to daily 15 minute meetings, and that perhaps, is counter-productive, anyway.

Client-Developer relationships are different for every project, and I advocate using simple rules that fit the situation.

Here’s an example of a system that works for me:

1. I write a on-page application story, describing everything the app is and does, and create a visual spec;
2. I create a list of the features the client wants in the system;
3. From the features list, I create a Product Backlog (in the same vein as your Scrum Product Backlog) with high-level user stories;
4. In consultation with the Developer, I create Releases or Sprints - three weeks worth of features that I have the Developer work on;
5. As the Developer works on the Release, I ask the client to keep adding to the Feature List. I use the list to add items to the Product Backlog, and we reprioritise the list and then go again with the next Release.

I like to keep fairly regular contact with developers - even just to touch base every second day or so - to make sure they have everything they need.

37signals, of Basecamp fame, have published their thoughts on developing web apps in their book, Getting Real. It’s definitely worth a read - but their philosophy requires some adaptations in order for it to be implemented in contracted development situations.