We’ve been working with a ton of teams in transition to an Agile development process lately and we’ve been trying to understand why many of them are frustrated by the change. They’re struggling with how to adapt their existing user experience practices into this new method of development and I think we know why.

In the “old” waterfall method of development, there are explicit milestones: first you develop requirements, then you create a design that meets those requirements, then you lay out the functionality that will implement that design, and so on. You can see when things are moving forward and you know where you are in the development process. (Of course, it never actually works this way, which is why so many are moving to an Agile process, away from the waterfall.)

From a user experience perspective, it’s clear what you need to do in a waterfall process. You need to gather any research that will affect the requirements, before the requirements are done. You need to test your designs before the designs are signed off. You need to evaluate the functionality as it’s being built. And so on. Every step has clear contributions and expectations.

In Agile, these contributions and expectations aren’t nearly as clear. Waterfall gave us nice “hooks” to hang our UX work on, but Agile doesn’t do that. The team breaks up work into small chunks and just starts chipping away at it. There’s no clear point when requirements are done (they are gathered in parallel with trying out the designs). There’s no clear point when design is done (it evolves over the duration versus being declared up front). It doesn’t seem that there are any clear hooks in an Agile process.

Interestingly, if you dig deeper, the hooks are there. In this issue of UIEtips, Jeff Patton concludes his two part article on his best practices for integrating user experience work into an Agile development environment. He talks about how teams he’s worked with have found the hooks and made it work.

Jeff will be sharing his wisdom on integrating UX into an Agile process at the upcoming User Interface 13 Conference in Cambridge MA this October. His is just one of the great full-day seminars we have at the conference. If you’re looking to create great designs, I suggest you check out the program.

How have you integrated your user experience methods into an Agile process. What struggles have you encountered? We’d love to hear your experiences.

2 Responses to “UIEtips: 12 Best Practices for UX in an Agile Environment – Part 2”

“This is the stuff we sketch or model to better understand what we’re doing. It only needs to be good enough to understand, to learn, to communicate quickly with our co-workers, then it can be thrown away.”

Using a whiteboard to communicate a UI, a concept and story is especially powerful when your audience cannot speak the same language. Used this a lot in a project recently in China where we were integrating a public web site and a few products requiring customer login. Being able to tell a story through white boarding really helped communicate to the IT team and they were able to walk away knowing what to do next in their development.