Agile + User Experience = Parallel work streams

Published Mon, Apr 7, 2008 by Austin Govella. Updated Mon, Apr 7, 2008.

There’s a thread on the IAI-members list about how agile and user experience work together. We’re using an agile dev process at Comcast, and it’s been the source of some frustration, so I was kind of snarky about some of the problems I’ve faced.

Snarky’s not constructive, so, as a penance, here’s something I’ve learned.

Like anything, agile works or doesn’t work based on the people you have, and the culture they function in. (Everyone can now say one giant, collective “duh”.) Regardless of whether it does or doesn’t work for you, I’ve noticed most environments require parallel work streams.

Why parallel workstreams?

Though Agile pretends to eschew documentation, it really wants to avoid unnecessary documentation. Agile likes lean. Do only what you must. This doesn’t mean no documentation. The team still needs a shared understanding about what it’s building.

In that sense, it’s better to refer to documentation as “shared understanding”. Whiteboards, napkin sketches, daily scrums, and annotated wireframe decks all provide shared understanding.

(In my experience, too, the more people who will see the “shared understanding”, the more time documenting the “shared understanding will take. Not an inherent truth; just an observation.)

Product managers and UX practitioners still need a vision. And, it’s still vitally important to examine possible impacts. (For example, how will this new feature affect flow through the site.) To that extent, planning, design, modeling will always be necessary prior to development.

Erin Malone mentioned several Yahoo teams have started a Sprint 0 with upfront planning. At Comcast, we don’t have an official sprint 0, but there’s a parallel product development track that dumps something new on to the sprint backlog. Essentially, they’re both the same thing: Plan before do.

For incessant waves of sprints, this means you design work for the next sprint while supporting work on the current sprint. With Fancast, supporting developer UX needs (answering questions, clarifying, collaborating on additional iterations) has become a full-time job. Someone else (or several elses) design features for the next sprint.

(There’s a fall-out assumption here: planning and design require more product, UX, and design folks than implementation does. Everyone can now say one giant, collective “duh”.)

There’s a danger here. If you do not accurately communicate how much work you have and how much you can do, you can get sucked into doing more than one person’s worth of work. That is, you support the current sprints UX needs, and you design all of the work for the next sprint.

That’s a lot of work.

This isn’t a problem with agile. This is a problem setting expectations and communicating status. However, I think agile can make this problem more likely.

With agile, the focus is often on development time. A feature might require 10 hours of development. It’s possible to require more than 10 hours to plan. It could take less. Again, it depends on the amount of shared understanding, the design literacy of your team, the actual impact the feature has on the current project, etc.

If you have four 10 hour development features, and they each require more than 10 hours of planning time, then you cannot crank out enough design work to keep developers fully occupied next sprint.

Parallel work streams require very clear expectations and status regardless of the development process you’re using. Using our above example, it’s imperative you’re clear that planning a feature will take longer than you have. Similarly, if planning suddenly requires more or less time, you need to communicate this change right away in a clear manner.

Thankfully, on top of being lean, agile is also about constant communication.

That’s my experience. The big unknown is whether it’s possible to support a rolling series of sprints without parallel work streams. Anyone seen this in action?

Talk About "Agile + User Experience = Parallel work streams"

Jon Moore said:

I think what you’re describing is a skillset bottleneck—not enough “UX” folks to go around. Classic agile solution is to have other members of the team (engineers, designers, product folks) pick up some of the simpler tasks, with UX review/guidance, and let the true UX folks focus on the hard/new stuff. On the engineering side, for example, we have backend engineers do some minor frontend work when our frontend guys are overbooked, allowing them to do all the crazy CSS styling stuff.

Do you think that kind of model would work? I’d imagine after working closely with a set of designers/product folk/engineers they would catch onto your style and tend to come up with an almost-there solution that could be quickly reviewed and tweaked.

Sat, Apr 12, 2008 at 01:32 AM

Austin Govella said:

One of my goals has always been to increase the team’s design literacy. That’s just good practice in any organization with any process. Design literacy enables faster, better, more advanced collaboration, and that’s exactly what an agile process needs.

We’ve divided user tasks on the site into four major groups, and we have a set of ‘generic’ requirements for each. (More like best practices for that kind of task.)

I’ve been struggling with the best way to communicate these requirements to both engineering and design. Any suggestions?

Tue, Apr 15, 2008 at 01:11 PM

Jon Moore said:

Well, at the very least I’d suggest throwing those requirements out on a wiki somewhere. If the generic requirements can also be elucidated with examples (and anti-examples!) then that might go a long way towards helping educate. Also don’t forget the “why” on these requirements—this is one of the easiest ways to motivate the requirements but it is often all to easy to leave them off (incidentally, this is why I think user stories which explicitly state the value they are extracting are great).

After that, I’d say it’s probably just a continual process of interacting with team members, and referencing the wiki docs when you do—“teach the team to fish.”

Tue, Apr 15, 2008 at 09:44 PM