Agile Design, O RLY?
We had a great Hashrocket Book Club discussion today about a Cennydd Bowles article on A List Apart: Getting Real About Agile Design. Our discussion revolved around the integration of our very XP-like process with traditional and so-called "Agile Design", the evolution of design activities that traditionally have been very waterfall-like and involving heavy research phases.
Les made a pretty bold statement that design people are stuck where developers were 10 years ago, prior to wide adoption of Agile.
Here are the rest of my rough bullet point notes, in the hopes of getting a discussion started about this important topic.
- There is a trichotomy* when discussing "design": Experience, Application and Graphic. Or sometimes you say "design" and you mean all three. That makes it difficult for everyone I know to talk about "design" without getting really confused.
- User experience design involves the entire interaction of a user with a business and its technology, which makes it different than application and interaction design, which has more to do with the design of screen interactions and forms and pages.
- Projects should have mini-milestones that represent "user journeys" as described in the article -- stories chained together to represent a path through the application -- and different than the concept of an "epic story".
- The meaning of iterations still presents issues (even to us) in terms of thinking that they constitute weekly milestones. I say that iterations are nothing except dumb timeslices that enable tracking of velocity, but I realize that is far from a universal view in Agile circles. See The Story is The Iteration as practiced by Hashrocket, Pivotal Labs and others.
- It's hard to envision experience and application design as happening after storycarding, since the storycarding process is dependent on having that design already done.
- There are ways to start intertwining design with Agile the way that we're practicing it, but not like in the Bowles blog post, because Hashrocket usually acquires clients that have their application design done. Except that's not actually the case now, because since Andrew came on board we're participating in the earlier stages of the project, even starting at the concept phase.
- There is value in developers championing the user experience throughout the project, being more than just programming robots. This implies that our developers have design savvy.
- Customers are not experts in experience and application design and they cannot replace designers on XP projects.
- The comparison in the Bowles blog post between software and the movie industry is flawed, because movie projects don't do small or often releases.
* Yes, I know that trichotomy is not really a word. But "dichotomy" implies two things, not three. Update: As pointed out by Thufir in the comments, it is a word. (I originally checked and didn't find it in my dashboard dictionary.)