Monday, Apr 7, 2008

Agile + User Experience = Parallel work streams

Design Business, Working better by Austin Govella

In an agile process with a rolling series of sprints, UX requires two, parallel work streams, clear expectations, and constant status reports.

4 Comments

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"

Register or Log In to comment