I've been working closely with Pivotal Labs over the past month. Each week I get together with designers and management to map out how design works in this cathedral of XP-flavored agile.

It was during one of these days that I had an epiphany. I felt like I had discovered the Rosetta Stone...a mars/venus split between design an development. Here it is: 

To developers, "iteration" means incremental release of working code. 
To designers, "iteration" means a chance to do something again. 

 Iterative Design 

Designers have been talking about the practice of iterative design literally for decades. This practice calls for designers to test designs and to immediately change and refine them, and then launch again. 

In his notoriously declarative style, Jakob Nielsen wrote in his 1993 paper Iterative Design, 

Even the best usability experts cannot design perfect user interfaces in a single attempt...[making] at least three versions of the interface is recommended.

For Jakob and generations of design professionals, an iteration is a do-over (and over and over). It's a presumed part of the process. 

Iterative Development

To agile developers, though, the word iteration means "increment," as in 'a small chunk of working code that can be released in a brief period of time'. Iterative, in this context, means that the software grows piece by piece.  

Agile developers do believe in going back and doing things again -- "make it green then make it clean" is a motto at Pivotal, and refactoring the software is a routine practice. But it applies only to the code; not the interface or interaction. 

Overlooking the Obvious

Consider the implications of this misunderstanding: Betty the designer approaches agile with an open mind. She finds comfort in the "iterative" approach of agile -- iterating (revising) her work has been core to her practice for years, and she's excited to work with developers who share this belief. Betty comfortably accepts limitations on her design process because she thinks that she will get a chance to revise, to do it again, and better this time.

But the design do-over doesn't ever get added to the the iteration plan -- there are always new features to launch, bugs to fix, refactoring to finish. Eventually, Mary falls back into waterfall methods, because it feels like agile doesn't really work. 

How have we misunderstood each other for so long?

It seems obvious in light of this realization that design needs the equivalent of refactoring, and it needs to happen routinely. "Make it green then make it clean" applies to everyone. 

Given this realization, it should be a relatively simple thing to devise a solution -- perhaps new story types? Design refactoring? More design input to the iteration plan? At some point, we will figure this out, but until then, understanding will go a long way.