Several weeks ago, I had the opportunity to talk to Rob Keefer of Pomiet about his experiences with Agile UX. Rob shared several techniques that he’s had success with over the years, including the Sprint Ahead/Behind approach. Several others I’ve talked to have used this as well.
For those of you who haven’t heard of this before, here’s how it goes: You start with a sprint zero which gives Design time to get out ahead of development. As development gets started setting up environments and infrastructure, design continues to craft design documents that can be handed off to development in a subsequent sprint.
After a feature has been developed, design comes back around and performs usability testing and iterate. The trick is that in sprint 2, you will be designing for sprint 3, testing what was developed in sprint 1, as well as working with development as they build what you designed in sprint 1. Oh, and iterating the design in your free time.
Perfectionism is a common trait among user experience designers. We are known for paying attention to the small details that make a big difference to users. Like QA testers, UX designers look for the holes in the design, catch the dropped balls and find where the approach falls down. Valuable skills to have on any team. But like any good thing, this talent can become an Achilles Heel. Perfectionism stalls the designer in endless meetings and revisions.
Carefully crafting every detail takes a lot of time. Adapting to change quickly generally translates to late nights redrafting wireframes to keep a team of developers from waiting, idle. If a change to the security requirements is made, using email addresses instead of an 8 character user name for instance, you’ll have to reexamine the entire experience looking for those ‘gotchas’ and reworking what you spent so much time creating. So designers take measures to protect themselves from change.
Here’s reality. Design happens in the same Catch-22 environment as development. You will never know everything you need to know before you start. Doesn’t matter how long you spend in discovery or how many business analysts you throw at the project. The digital world is an ever changing environment where business needs shift quickly, the technical landscape evolves, and we never stop learning about our users. As we design and build, we apply the knowledge that we have, and discover new things along the way. No one should be expected to ‘get it right the first time’.
I’m on a mission ladies and gents. The goal of this mission is to figure out how to do Agile UX successfully and without pain. I’ve been a fan of Agile for years. While I enjoy losing myself for days in the land of wireframes and userflows, I find them largely ineffective when it comes to creating software. It’s a self-serving endeavor that creates a divisive atmosphere. No one has time to read the darned things and they get in the way of team members talking to each other. I’ve tasted the promised land of sketching together with developers and whiteboard as spec and I want more. Please don’t make me go back to waterfall, I beg of you.
The talk about Agile UX is increasing slowly, but there seems to be relatively few who have successfully integrated their user experience practice into an agile, cross functional team. I’ve experienced some wins, some outright disasters and I want to share what I’ve learned with you.
Part of my quest is also reaching out to others who have had good results. There are common problems like maintaining the big picture, getting in usability testing. Others may have solved them in their organizations and I want to learn from them. So, if you are an Agile UX (or Lean UX) evangelist, someone who has had successes, or want to talk about your agile challenges, drop me a line. Contact@practicallyUX.com