Agile+UX - remembering what a team's sposed to be

Published Tue, May 18, 2010 by Austin Govella. Updated Tue, May 18, 2010.

The inimitable Dan Brown passed along an email from a friend of his:

At my current job, we have an on staff UI/UX person and since we adopted Scrum across our entire team about two months ago, she has been struggling... I fear our UX person has basically just stopped participating in team activities to everyone's detriment... I'd appreciate any thoughts on how I might help her re-engage and figure out how she might adjust her work to fit in better with an agile process.

Some sad Scrum master

My Life as a Panther

I was a Boy Scout when I was younger, and in Boy Scouts, groups of 5-10 boys are organized into units called _patrols_. And everyone in the patrol is about the same age, so it ends up being a peer group. Every patrol has a Patrol Leader and an Assistant Patrol Leader who are tasked with managing 5-10 rowdy boys who spend a lot of time playing with knives and lighting fires. It's a good time.

Once, when I was a Patrol Leader of the Panthers, I had this one kid named Nathan who was more of a recreational scout. You know: there for the camping, axe throwing, and co-ed activities with girls from Explorer Troops. Now, in Boy Scouts, whenever you go on a camping trip there's a set of chores the patrol has to do. Someone has to cook. Someone has to do the dishes. Someone has to dispose of the trash. Someone has to collect firewood.

There's no use arguing about it. Those chores have to get done, so you make up a chart with the boys names down the left side and the chores across the top and you put X's next to boy's name when it's their turn to do that chore. And you rotate through so everyone does every chore in turn. It's a fair system.

Except for Nathan. He wasn't into any of it. Especially dishes. Whenever it came time for him to do the dishes, without fail, I'd have to go help just to make sure he did some of them. I helped because it was my job as the Patrol Leader. If the team chore didn't get done, the team didn't eat, or didn't have a fire, or would have to fight off bears in the middle of the night. When Nathan failed, the team failed.

The bullshit behind agile+UX

There are a lot of agile teams where we like to say "the UX person has been struggling". We talk about culture clashes, misunderstandings, wagile, sprint 0, and scrums. And there's often a good bit of derision and disrespect that drips from the engineering community about UX, in general.

I would like to take this opportunity to call bullshit on UX not integrating with agile.


Agile is built around teams. Your UX person isn't struggling, your team is struggling. If one person fails, the entire team has failed. Your burn downs, WIP charts, bug triaging, and velocity mean fuck all if any member of your team from any discipline "is struggling".

What you really should be saying is "my team is struggling with UX and not one person in a room of engineers can do anything to help her out". Really? No one can help her? Is the asshole quotient so high, that she's actually stopped participating?

Working as a team

Team's aren't rocket science. Differences in the way designers and engineers think are important, but they're not stopping you from succeeding. It's not the difference in process. It's not different goals. It's not the length of the sprint. When you phrase the problem as a team problem, and not a UX problem, it's obvious how you can better integrate UX.

Do you need wireframes but not have them? Then help your team member with the wireframes. Do they say you need personas, but not have any, then learn how to make personas. Do they say you need to do some testing, then help them do some testing. Do you not understand why you need wireframes or site maps or personas or testing? Then learn about wireframes, site maps, personas, and testing. Does an engineer who takes time out of their sprint to help a team member then complete less code? Yes.

But there's no use arguing about it. Those chores have to get done. Your team member said they needed to get done. The same team member that never questions when you say a chore needs to be done, has said a chore needs to be done. If the chores don't get done, the team fails. Not one person. Not one discipline. The whole, entire team. If you release something with shitty UX, it wasn't UX's fault. The Team Released Something Shitty.

The fact is, a lot of engineers on a lot of teams are Nathan's. They'd rather light fires and throw axes and chase Explorer Scouts. But someone's got to do the dishes. And whether you like it or not, UX is the dishes, and you've got to get it done.

Next time you think your team has an individual problem, rephrase it as a team problem and see how _the team_ can make sure all of the chores are done. If UX isn't integrating well, I'm willing to bet the few UXers are less likely to be the culprits than the many engineers. Just playing the odds...