Doug Winter — Mon, 01 Feb 2010 19:34:05 GMT

We have been using a process very like the one you describe extremely successfully for the last few years, although only after a few bad starts and screw ups, of course.

We make a clear distinction between *what* and *how*. We want a well defined UX, with a complete wireframe stack *before* we plan a release. The release plan provides a good structure that we expect to conform to during the build – although Agile allows us in theory to change everything we’d consider that to be failure of planning.

What we do use the agile process for is to enable us to flex scope *instead* of either time or quality, and I think this is it’s greatest strength. We do therefore need to plan how the UX would work if a feature is omitted completely – but this is generally something you can do with a well designed UI. What we do NOT do is completely rearchitect the UX each iteration – UX is just too fragile and expensive to change.

In effect I think the wireframes are not part of the specification, they are part of the deliverable and our (often long) Iteration 0 reflects this, with the wireframes considered a key deliverable, to help the customer work out what they want and how it might work.

Clearly a lot of attention is still required to ensure we have happy customers – the overall promise of Agile that it naturally produces the best ROI is probably only possible in a situation of 100% trust, not something an agency will ever encounter. But it does mean we can flex as we need, rather than committing to a completely defined triangulation of scope, time and quality – which is what causes developers such pain.

Boxes and Arrows: Comments by Doug Winter