Monday, January 30, 2006
Agile UX - What about our Process?
2006 will have many of us arguing the merits and issues of adapting User Experience to Agile software development. Having designed UX processes in industrial-strength development organizations, Don Norman’s conclusion to a recent discussion post resonated with me:
Our recent online discussion was spurred by a question:
What kinds of process and practice conflicts are there between UX and Agile methods?
I find no inherent (designed-in) conflict at all. In terms of practice values, there's a strong user-centered (albeit, customer) focus in Agile design. Requirements are based on identified customer priorities. Agile allows for the flexibility over time to iterate a design until the best set of features and interactions are achieved. However, significant differences show up in how a given organization performs using Agile teams.
Why use Agile? Reducing time to delivery is, of course, the main driver. Agile also leverages available skills in a synergistic team. In other words, Agile teams make do with the talent they have, and use cooperative practices to manage design decisions and ensure quality.
But the organizational pressure of this driver places intense demands on teams that are newer to Agile. The conflict shows in the team response to the inherent time pressure of the demand to use Agile in the first place, then having to use Scrum or XP in development, having to baseline code every day and deliver versions every month (or so). These teams are in the midst of learning new process and under management pressure - which offers very little psychological space to afford UCD, especially traditional usability, any entry point.
Who is using Agile? Many firms with large user bases are using Agile in lower-risk projects, but not across the board as a development process. There are many reasons for this. Agile does not scale well to large-scale, mission-critical systems. And it makes sense to continue maintaining highly-stable systems (think telecommunications, industrial processes, military information systems) with well-known, pre-existing successful methods. And we’re not suggesting the continuance of Waterfall methods, even in these cases. Rather than risking moves to Agile, stable and large-scale systems have been “ported” to spiral methodologies, which afford rapid delivery of incremental enhancements while maintaining quality control.
What are impacts on UX practice? There have been discussions and several recent articles on “Agile UX,” and there are certainly impacts on process and approach. There’s not necessarily conflict with adapting UX process, since there IS no established "UX process," except as specific firms have determined as their best practices. UX practices within the frameworks called “process” have to adapt to change as much as software development.
In my opinion, our methods and tools are, or have been, flexible to accommodate many situations. In Agile team projects, what has worked for me has been to involve the product manager in all user field research or usability work. They are able to observe authentic user responses to prototypes and learn directly what features are most important to the user-at-work. Since the product manager remains responsible to customers and requirements, they are literally able to decide on features and priorities while in the field. I'm not saying this is an Agile UX process, instead I am just "being agile" with the constraints of my client and modifying methods to fit the demands of schedule and user access.
How does UX look to the Agile team? The product or project managers are not doing paired-coding/testing, since they are focused on the customer's need. I've used rapid field usability interventions in partnership with the product manager, sometimes a day or two in a field location, scheduling hour onsite sessions with current and potential users of the product line. We work as a trio or small group in the user's office or a conference room, doing rapid debriefs with the client team after the sessions. I usually deliver a topline report within a day or two, then work in parallel time to do some in-depth analysis for up to a week, uncovering any major hidden issues and preparing solid design recommendations (which may be recommendations for a next release, and not the current iteration). UI specs are not used, there is no time to do one. In most "true" Agile projects, requirements are open to change during development - and our field testing alters those requirements. So we use prototypes only, and I will deliver design briefs or detailed feature proposals or wireframes, with the prototype.
Rather than suggesting we should define some sort of Agile UX process, instead its up to us to realize and experience Agile is something very different, it is an "anti-process," a kind of agreement among professionals to play well together. The radical time savings is gained by team design and development as a unified, self-managed small group. Team synergy is generated by having each member of the team performs their role as an individual, and the team's expert, and as a full-time team member. But it only works if each team member is in constant communication, (or at least daily) around the developing needs of the project. That means informalizing our methods to quite an extent, perhaps, but it works well, because the goal is to evolve a product line through multiple increments of key feature sets, not to deliver a full and perfect product on Day One.
Some of my favorite links to Agile methods and ideas:
Agile manifesto
Extreme Programming
Martin Fowler
Alistair Cockburn's Crystal Method
Yahoo Agile UX Group
A Great Reading list on Amazon
“Agile methods are good. It is where the future is. Learn to modify our procedures to fit - become a team player. And rejoice, these methods care about usability. They want us on the team. They simply won't let anyone slow them down. More power to them.”But most organizations I know of do not bet the farm on Agile. Software product organizations use processes appropriate to the needs of a project. High-criticality, large user base products remain wedded to traditional processes, even when compressing release cycle intervals. For niche products, lower-volume tools, or new product concept requiring an immediate market splash, Agile practices make sense, and are being adopted side-by-side with traditional methodologies.
Our recent online discussion was spurred by a question:
What kinds of process and practice conflicts are there between UX and Agile methods?
I find no inherent (designed-in) conflict at all. In terms of practice values, there's a strong user-centered (albeit, customer) focus in Agile design. Requirements are based on identified customer priorities. Agile allows for the flexibility over time to iterate a design until the best set of features and interactions are achieved. However, significant differences show up in how a given organization performs using Agile teams.
Why use Agile? Reducing time to delivery is, of course, the main driver. Agile also leverages available skills in a synergistic team. In other words, Agile teams make do with the talent they have, and use cooperative practices to manage design decisions and ensure quality.
But the organizational pressure of this driver places intense demands on teams that are newer to Agile. The conflict shows in the team response to the inherent time pressure of the demand to use Agile in the first place, then having to use Scrum or XP in development, having to baseline code every day and deliver versions every month (or so). These teams are in the midst of learning new process and under management pressure - which offers very little psychological space to afford UCD, especially traditional usability, any entry point.
Who is using Agile? Many firms with large user bases are using Agile in lower-risk projects, but not across the board as a development process. There are many reasons for this. Agile does not scale well to large-scale, mission-critical systems. And it makes sense to continue maintaining highly-stable systems (think telecommunications, industrial processes, military information systems) with well-known, pre-existing successful methods. And we’re not suggesting the continuance of Waterfall methods, even in these cases. Rather than risking moves to Agile, stable and large-scale systems have been “ported” to spiral methodologies, which afford rapid delivery of incremental enhancements while maintaining quality control.
What are impacts on UX practice? There have been discussions and several recent articles on “Agile UX,” and there are certainly impacts on process and approach. There’s not necessarily conflict with adapting UX process, since there IS no established "UX process," except as specific firms have determined as their best practices. UX practices within the frameworks called “process” have to adapt to change as much as software development.
In my opinion, our methods and tools are, or have been, flexible to accommodate many situations. In Agile team projects, what has worked for me has been to involve the product manager in all user field research or usability work. They are able to observe authentic user responses to prototypes and learn directly what features are most important to the user-at-work. Since the product manager remains responsible to customers and requirements, they are literally able to decide on features and priorities while in the field. I'm not saying this is an Agile UX process, instead I am just "being agile" with the constraints of my client and modifying methods to fit the demands of schedule and user access.
How does UX look to the Agile team? The product or project managers are not doing paired-coding/testing, since they are focused on the customer's need. I've used rapid field usability interventions in partnership with the product manager, sometimes a day or two in a field location, scheduling hour onsite sessions with current and potential users of the product line. We work as a trio or small group in the user's office or a conference room, doing rapid debriefs with the client team after the sessions. I usually deliver a topline report within a day or two, then work in parallel time to do some in-depth analysis for up to a week, uncovering any major hidden issues and preparing solid design recommendations (which may be recommendations for a next release, and not the current iteration). UI specs are not used, there is no time to do one. In most "true" Agile projects, requirements are open to change during development - and our field testing alters those requirements. So we use prototypes only, and I will deliver design briefs or detailed feature proposals or wireframes, with the prototype.
Rather than suggesting we should define some sort of Agile UX process, instead its up to us to realize and experience Agile is something very different, it is an "anti-process," a kind of agreement among professionals to play well together. The radical time savings is gained by team design and development as a unified, self-managed small group. Team synergy is generated by having each member of the team performs their role as an individual, and the team's expert, and as a full-time team member. But it only works if each team member is in constant communication, (or at least daily) around the developing needs of the project. That means informalizing our methods to quite an extent, perhaps, but it works well, because the goal is to evolve a product line through multiple increments of key feature sets, not to deliver a full and perfect product on Day One.
Some of my favorite links to Agile methods and ideas:
Agile manifesto
Extreme Programming
Martin Fowler
Alistair Cockburn's Crystal Method
Yahoo Agile UX Group
A Great Reading list on Amazon
My Four Favorite Things, categorized
Continuing with the "Four Things Meme"
Like a contagion, I caught this bug from Peter Boersma, and now find myself at the blog, perhaps a good reminder to get some fluff on the page, perhaps opening up some space for blogging Important Things.Four Jobs I've Had
1. All night janitor in an off-Vegas type Supper Club
2. Bartender at Dayton's largest downtown hotel
3. Biomedial engineering (human subjects) research assistant
4. Human factors engineer at AT&T Communications
Four Movies I Can Watch Over And Over
1. Waking Life
2. Baraka
3. Fight Club
4. Lord of the Rings
Four Places I've Lived
1. Milwaukee, Wis
2. Springfield, Mass
3. Dayton Ohio
4. Cincinnati, Ohio
Four TV Shows I Love
1. Daily Show
2. Colbert Report
3. Formula One racing
4. Victory by Design (with Alain deCadenet)
Four Places I've Vacationed
1. Amsterdam
2. Rome, Venezia, Assisi, Maranello
3. Slovenia, Prague
4. Costa Rica (Pacific coast)
Four Of My Favorite Dishes (and drinks)
1. Pasta alla fruitti di mare (with Chianti or Amarone)
2. Killer chili text-mex (with Burning River or other high-hopped Pale Ale)
3. Homemade fish chowder (with Franciscan Chardonnay or Chandon Napa sparkling)
4. Grilled pork loin and garlic mashed potoatoes (with a great Cabernet such as Fetzer or
Four Sites I Visit Daily
1. New York Times or Salon.com for news
2. Bull/Not Bull for market information
3. Huffington Post for political news
4. Google or Clusty for search
Four Places I Would Rather Be Right Now
These are places I haven't been ...
1. Chile
2. New Zealand
3. Nepal
4. Rio de Janeiro
Four Bloggers I'm Tagging
Here goes:
1. Dirk Knemeyer
2. Patricia Kambitsch
3. Christian Long
4. Keith Instone
