It’s a rare and special moment when life hands you a new first. I had one just a few weeks ago, when I found myself on my first panel discussion. It was at a gathering of software product managers who use Scrum, an Agile software development approach.

Here’s what I learned: when speaking on a panel, you never know what question you’re going to get next.  That makes each one feel a bit like the pop-up that gave me a black eye the last time I tried to play softball. I could see it coming; it appeared to be slow and easy. But alas, I just couldn’t land it in my mitt.

Normally I love to spout off. To an audience? Even better.  But this was a little different, because I’m sensitive to the way that the Agile and UX communities talk and think about each other, and, frankly, because the questions coming from the audience were so very specific about how to run an Agile project. So I was kind of shy.  I did a fairly good job dodging questions until someone threw a zinger aimed straight for me…

“How do UX people measure burndown?”

Crack. Swish. Thud. No answer.

Burndown, in case you’re wondering, is basically a measurement of how quickly the team is doing the work. Each day, everyone gives an estimate of how many hours of work they have left, and the estimates are all added up, and that’s the burndown, or velocity, of the work. If you measure this regularly, you should see a steady and precipitous drop, steep and to the right. That’s a healthy project.  Because Agile evolved as an antidote to slow, unfathomably-difficult-to-predict waterfall projects, knowing that things are progressing at a brisk pace and that the work is actually likely to finish when predicted is understandably important.

But I have to say, the question stumped me. Part of me wanted to quickly manufacture a way to actually measure UX burndown, to show that us UX folks can play nicely. But another part of me—the rude, argumentative part—  wanted to say, “that’s not the point!”

Flareups, not burndowns

I’ve thought more about this since then, and here’s my beef: where UX design really has the most to offer Agile is not in getting the nitty gritty design work done. Placing the buttons and aligning the labels must be done just as surely as dotting your I’s and crossing your T’s. But that’s not the high value UX work.

No, what UX designers offer that’s special is help building a vision for what the product can and should be.  This is not a reductive “getting things done” approach.  It’s a generative “what does this have the potential to be” kind of approach. A good UX designer should encourage the team to ask that question, facilitate a process that brings the whole team along in answering it, and then make those answers tangible, doable, and, yes, a little bit pretty.  (Jeff Patton, who is one of the strongest and most coherent voices for Agile + UX unity, has more to say on the importance of the designer as facilitator over on his blog, Agile Product Design.)  Basically, I’m talking about the opposite of a burndown. Dare I say it? A design flareup!

Sprinting with design

That’s not to suggest that design must equal bloat. In fact, at Adaptive Path we have some ideas that we’ll be sharing in our upcoming two-day workshop Good Design Faster for how to make design as lean, swift, and results-oriented as Agile. Much like Agile development, our take on design sprints includes short, fixed periods of productive abundance and a “finished” product at the end—in our case an interactive prototype. (You can find out more if you’re interested, and register with the code “BLOG” to save 10%.)

I do believe that Agile and UX can find a way to work peaceably and productively together. In fact, many teams are doing so already.  But we haven’t gotten very good at sharing the hows and the whys with folks in the Agile community yet. It’s time. If you’re doing interesting work with Agile teams as a UX designer, please consider submitting to Agile 2009, so we can all learn from each other.