Or is it UX in my Agile? I’m too young to actually remember the famous 80’s Reese’s Peanut Butter commercial, but the ad still rings true today—it doesn’t matter how you look at it, chocolate and peanut butter go good together. The same goes for Agile and UX.

If you're not familiar with Agile Software Development, in short it's simply a process by which small, self-organized and cross functional teams work to create quality software and respond to changes in requirements faster by breaking down the development cycle into smaller increments. Don't worry, I wasn't that familiar either, but after spending the last three days in Agile training it's definitely a bit more clear. Whether or not you are working with a team of software developers, the principles within Agile hold some pretty interesting implications to how we as designers deliver quality products and I hope to spend a little time expounding on that now, and in the near future. These concepts have been around for a while (as I'll point out below), but their adoption within design as a whole is still relatively young.

What spurred this discovery process on for me was that during my recent training I was excited to hear our team's (Product and Engineering) interest in how UX fits into the Agile world. I felt as though the question on everyone's mind was, "Where does UX end, and the Agile process start?" The answer is, "It doesn't." The two are intertwined and both are crucial in bringing quality products to our users fast.

UX in Agile

I came home after my last day of training eager to dive deeper into UX within Agile development and the first place I started was Jeff Patton’s blog. Jeff is a consultant and expert in Agile Development processes and an advocate for adopting Agile principles within UX. If you don't know of him, don't worry, I haven't followed his work closely that much either. This probably has something to do with the fact that his last article written was in April of 2009. Either way, it turns out Jeff is still kind of a big deal within the Agile camp and I also found out he lives right down the road from me in Park City (but that's beside the point).

Jeff’s Twelve Best Practices for Adding UX Work to Agile Development is well worth a read. Here’s the full list for reference though:

1. Drive: UX practitioners are part of the customer or product owner team
2. Research, model, and design up front – but only just enough
3. Chunk your design work
4. Use parallel track development to work ahead, and follow behind
5. Buy design time with complex engineering stories
6. Cultivate a user validation group for use for continuous user validation
7. Schedule continuous user research in a separate track from development
8. Leverage user time for multiple activities
9. Use RITE to iterate UI before development
10. Prototype in low fidelity
11. Treat prototype as specification
12. Become a design facilitator

Agile in UX

Above I mention how crucial both UX and the Agile process are in “bringing quality products to our users fast”. It’s that last word “fast” that hangs a lot of people up and even what Austin Govella calls the “secret lie lurking behind agile methods.” The thing about Agile is it's not necessarily faster, it’s rather a solution to allow change in product direction every few weeks rather than every few months. This value is no doubt closely related to speed, but it’s more about efficiency than rapidity.

Unfortunately, fast and UX have never really been synonymous. UX practices aren’t necessarily slow either, but they do take time to do well. So how do we then address this issue and keep up with the efficiency of Agile processes? Anyone writing or speaking on the topic will no doubt mention something to the effect of parallel workstreams. It’s #4 in Jeff’s list above and Austin Govella sheds a bit of light on the topic from his experiences at Comcast on his blog. Lynn Miller, Director of User Interface Development at Alias in Toronto, Canada writes about this concept of parallel workstreams in her paper, Case Study of Customer Input For a Successful Product.

Another way to stay nimble and design quickly is to integrate the product owners and appropriate stakeholders into UX processes. Govella refers to this part of the parallel paths as “shared understanding”. Whiteboards, paper napkin sketches, and annotated wireframes are all examples of shared understanding. Whatever the deliverable it’s crucial that as many people can view this shared understanding as possible so integrating them into the actual development of these tools helps the team stay agile. Adaptive Path came up with a great process and name for this called Sketchboarding. Check out the video below for more details on how to create a Sketchboard.

Lean UX

Believe it or not there’s actually a term for aligning UX processes with Agile development—Lean UX—and it’s quite the hot topic. A quick search at Jared Spool’s uie.com (User Interface Engineering) for “Lean UX” will result in quite a bit of reading material, but I think the title of Smashing Magazine’s article on the topic sums it up nicely—“Lean UX: Getting Out of the Deliverables Business”. Here’s a little blurb from the article:

“Traditional documents are discarded or, at the very least, stripped down to their bare components, providing the minimum amount of information necessary to get started on implementation. Long detailed design cycles are eschewed in favor of very short, iterative, low-fidelity cycles, with feedback coming from all members of the implementation team early and often. Collaboration with the entire team becomes critical to the success of the product.”

There’s still a lot to learn here (and a lot of “un-learning” for that matter) but as I dive deeper into some of these processes at work I hope to share further learnings and insights on how we can improve our workflow as designers and get quality product out the door for our customers faster.