Wednesday, September 17, 2008

UX and Agile, how do they mix?

So there has been some discussion lately about usability and agile, and whether the two work well together. Alan Cooper's keynote at Agile 2008 was a rally for the agile community at large to start folding in the UX role and taking advantage of it. I spent 7 years in the usability field, and hearing him speak on this almost made me want to get back into it. This topic has also come up recently in LinkedIn group discussions and also with Mike Cottmeyer at VersionOne.

I commented to Mike's blog post about Agile and UI Design with this summary: "Agile engineering practices (especially TDD) are supposed to reduce the time between writing code and finding functional bugs. User experience skills are supposed to reduce the time between writing the code and finding usability bugs..."

Something we have to recognize is that user experience is a greatly misunderstood and undervalued field. Like Agile, UX folks have been struggling for a few years (since the '70s in software) to get the masses to understand the need for a user advocate and user modeling. Agile has started to push the concept of getting close to the customer, but some people think that this is enough to bridge the void when in fact it is not.

If you are working on a simple commercial website, then there is a good chance that you can be a follower of others and simply borrow from the best. This assumes that your leaders either lead because they have the most usable product, or because they spent a lot of money on usability studies.

If you are working on a true application, say an operating room management system (something I did for 4 years), you have a different view to usability. It is one where a system can functionally do exactly what it should, but a human might make an error using the software that can lead to a patient death. A decimal point error in medication dosage can equal death. A unit of measure error can equal patient death. This is a place where usability is imperative to the process. Most systems/projects fall somewhere in between these two points and usability is a differentiator and an added value, but not necessarily a requirement for entry.

UX folks are experts at understanding what the user can't understand themselves. Just like agile teams are taught that customers can't explain all the requirements up front, UX folks know that users can't understand how the screens should look/work. But there are scientific ways to figure this out by working with and observing users. Remember that the "customer" might be the head of the OR in a hospital making the decision to buy your software, but they won't be using your system like the nurses and surgeons directly in the OR. The UX person quickly realizes that the colors on the screen need to be changed for the lighting in the OR, even if during the sales demo they look ridiculous. UX is about uncovering user behaviors that aren't obvious to the developers, product owner, or even user themselves.

Can these folks fit into an agile team? Definitely. They are kind of like an SEO expert that reviews everything going out the door and mentors the team on certain standards and consistencies that need to be met. They are also like the lead architect that needs to look across the backlog and start creating a high level plan for system flow and structure. They can't just whip out screens on the first day of the sprint and reach perfection. UX sometimes requires focus groups and real user testing (think one-way mirrors and mouse recording). These are the sessions where the size and color of a button can be changed slightly to reduce error and increase efficiency.

My summary is this: there's a lot of gray area today on how much up-front design should be done on an agile project. I believe that same issue will arise with UX resources. UX people are going to struggle to fit in the agile culture because of the nature of their role and difference in speed between the agile team velocity and the delay of setting up controlled user tests. But, they will figure this out over time. It's more important to involve them early and let them see as much as they can so they can start adding value.

Update (11/26): Here's a great example of what usability can add to the process. Here's a great example of specific tasks the usability role can add value to.

No comments:

Post a Comment