On the agile-usability list, Jeff White pointed to Jeff Patton’s article, Twelve emerging best practices for adding UX work to Agile development. He asked for comments from the “more traditional agilists”. I’m not sure how traditional I am, but I commented as follows:

I think it’s just fine, and coming from Jeff I’d expect nothing else. Items that made particular sense with me:

1. Drive: UX practitioners are part of the customer or product owner team

Of course. Otherwise they’d have to be part of the technical team. But then the customer / product owner is hampered in making the necessary tradeoffs between UX concerns, price concerns, and timing concerns.

4. Use parallel track development to work ahead, and follow behind.

For best flow, the customer-side people always need to work ahead and follow behind in Agile. Naive teams try to jam all the customer planning and disposing into the same iteration as the work is done in. This is often called mini-waterfall, and it works no better than regular phased waterfall, and is less interesting because there’s less water crashing down like thunder.

I envision what Jeff is talking about here as a sort of refinement process. Looking a few iterations out, UX people sketch what needs to happen. Looking one iteration out, they define actual work that needs to be done next iteration. Looking back, the observe the result of what they’ve asked for, and determine changes.

Perhaps this needed to be said. If so, it needs to be said for the whole product-owner community, because it is exactly what any product owner needs to do.

5. Buy design time with complex engineering stories.

Yes. UX matters really do not pervade every line of code one writes in an application. Under one UX button click there can be a mass of code – and that mass of code can just as well support the UX hand-wave or UX cough or UX eye-flick that will be the ultimate interface.

The operations of the application will always be pretty much the same, though how they are threaded together may vary. Good system design makes these operations modular anyway. Therefore there probably are complex engineering stories available, and doing them is probably safe.

Caveat: Jeff calls these “engineering” stories. I would not, just because they do not have UX aspects, let this idea justify “technical” stories. On the contrary, these are the guts of value-bearing stories. The example he gives of the Sketchbook File Save / Load is a perfect one. This is a feature, not some technical enterprise like define a database or build a file system. And so it should be. Stories should always be value-driven.

It’s all good. As whatever level of Agile Guru, Agile Curmudgeon, or Agile Jerk I might be, I approve Jeff’s message.