Doing (or Not Doing) Agile UX

Twice in the past month, I’ve found myself responding to developer colleagues of mine who have been encountering difficulties working with UX folks as part of Agile project teams. The development teams want to jump right in and start building and collaborating, but the UX designer prefers working separately, handing off requirements once they are largely defined, implementation detail and all.

Having worked as part of Agile project teams in the UX lead role at a couple of different companies, I’m familiar with that situation. So I’m always eager to share my experiences from the “design side” and help explain some of what might be going through that UX designer’s mind. Because, in many ways, I was that stubborn, documentation-happy designer. (And alas, in a client-services scenario, the road to project completion is covered in virtual paper…)

My first exposure to the Agile project process was at a technology product company I worked for a little over five years ago. And, from the start, I hated it.

Having honed my project skills at an agency where a spec document of 100+ pages was a source of pride (See how comprehensively we documented the system?), I was loathe to discard what I viewed as an essential skill. Shorter documentation, in theory, was not necessarily a bad thing, as my idea of a good time definitely does not include wrestling with Format Painter in Word, or cutting and pasting boilerplate language about recurring functional elements. But the idea of no documentation, as communicated to the project team by our SCRUM master, was something that seemed completely unworkable.

And it didn’t work, at least not at first. Our project was a chaotic mess! All of us were new to Agile and unsure how to proceed. The SCRUM master dealt with uncertainty by attempting to order us to do things in a very prescribed manner, which further alienated him from the rest of the team. I dealt with the uncertainty by doing a little prototyping and a little documentation (Agile be damned!), both because it was what I was comfortable with and was what the developers were, ironically, seeking. The developers and I ended up working together very collaboratively, bonding over our mutual distaste for our methodology-obsessed project lead, who couldn’t see that we were following the spirit — if not the letter — of a quick build-and-release process.

Now, it took me quite awhile to figure out the unpleasant parts of that experience had very little to do with Agile. Inexperience, clashing personalities, different expectations about work style and product… these were far more powerful forces.

But the positive parts were also there: I discussed implementation approaches with developers, created quick prototypes in code, and helped QA my own work and that of others. These were things I’d always loved doing. But it was only later, on a second go-round with Agile that I learned that they — along with an experienced, good-humored project lead — were in fact all valued as elements key to a successful Agile project.

Ah, but what about that damned documentation? And other things, like pixel-perfect wireframes and comps, that I still clung to as some measure of familiarity and control?

Well, those things were hard to (mostly) give up. It helped that my prototyping skills improved to the point where I could demonstrate more complex interactions. And I became more comfortable with group technical and UI design sessions, once I’d had time to chew on some of the bigger problems and develop a high-level understanding of what was needed. (I still shudder at the idea of design-over-my-shoulder, as epitomized in this terrifyingly cheerful 37signals blog post.)

Even so, what ultimately made things work was both gaining the trust of the developers on my team and learning to trust them. And that takes time, as we silently size each other up — Does this person know what the hell they’re talking about? Will my design be mangled? Will this person design something that can’t be built? — and are able to eventually dismiss fears as we see how we work together and what we actually create.

Once you’re able to see ideas take shape in ways beyond what you imagined, all due to the input of a strong team, it becomes much easier to present work without having figured out all the details in advance, and to be open to criticism and feedback from anyone, not just other designers. And, hardest of all, it even gets easier (if never completely comfortable) to admit when you don’t necessarily know the best way of doing something.

In fact, it ends up being lot more fun when you let demonstrably awesome designers and developers surprise you with how much more they can do.