There’s a good summary of how agile works in the world of design (and development’s not too different either).
It paints a fairly detailed picture of how designers can work in an agile environment, but simulatenously makes it sound both difficult and easy. Yes, it can be hard to cope with incremental design requests, and I’d also add that this is where the problems start to sneak in.
The article makes it sound as though wholesale changes must be accommodated with ease, and that the design is only done incrementally alongside the development. However in reality, there is usually a fixed budget available, and if the client decided that (in the provided example) that they wanted to drop the review system and build a messaging system instead, then this is a legitimate case for a change request. Just because you’re ‘agile’ doesn’t mean you shouldn’t make the impacts of changes clear to the client. Something may have to give – either a feature, or more money needs to be forthcoming.
It was a bit surprising that the article didn’t emphasis this more. Explaining the impacts of changes is a key part of an agile project. If you don’t do this then your project is not going to be any better than the waterfall projects that everyone runs away from.
Also, I’ve found that the design is still done in advance of most of the development. Developers can’t build something without guidance as to what it will probably do, and they’ll be using either an approved design, or wireframes to start with. I can’t imagine how it would work if designers couldn’t provide any indicators as to what it might look like.
This article talks about a very pure version of Agile – more along the lines of Lean, and most people will probably find themselves in a hybrid agile/waterfall environment where there is more than a bit of certainty about what will be delivered, and the design will probably be started before development begins.