The question is not “how do you fit UX into Agile”, its “how do you fit Agile into UX”

Comment by Anders Ramsay on September 25, 2009 at 11:59am

Fundamentally, a UX design under Agile management would change in two key ways. First, single-phase discovery, research, design, would become iterative. So, one might go through much smaller versions of each of those phases to simply design (and work with developers to build) the core piece of the overall product. Then, one would effectively grow the product and the UX with iteration. Second, heavy documents, such as functional specs, would be replaced with lean documents. For example, an Agile replacement of a "comprehensive" spec might be
medium-fidelity prototype + conversation with customers/developers + iteration = specification

Oh, and almost forgot, last but not least, all of this would need to be founded on a strong foundation of Agile thinking, such as timeboxing, sustainability, "There is Only Us" etc.

To be clear, UX would be less a role and more a literacy. While there might be a UX specialist on the team, they are only facilitating the design work, since the team as a whole should be actively participating in conceiving and evolving the solution.

Comment by Austin Govella on September 28, 2009 at 6:58pm

Jason wrote: "The point of re-framing the question is to directly challenge the UX community to rethink its approach and bear the burden of transformation in order to move towards supporting a more effective and enjoyable way of actually delivering real, live user experiences for customers."

Jason,

Never in my life has the UX community not born the burden of transformation towards more effective and enjoyable ways of blah blah blah.

UXers are typically gap-fillers meaning their job roles shift based on the shape of the organization and project they're on. Are the developers good interaction designers? Sweet. We won't do wireframes. Is the project manager an idiot? Ok. We'll crank out a schedule and bug people about it. Is the product management lacking? No problem. We'll whip together a product strategy.

Do the developers need something tomorrow morning so they can deliver in two weeks? Not a problem. They'll have it.

UX is not the barrier. Bullshit is the barrier.

Comment by Austin Govella on September 28, 2009 at 7:11pm

Anders,

I know you've thought more about this but I thought your comment here was too simplistic and wanted to flesh it out.

The most important shift is that product development, vision, and strategy activities are not squeezed into the agile life-cycle. These are not "development" activities. This covers generative research, modelling, and IA.*

That leaves interaction design and evaluative research to be integrated with agile lifecycles, and these fit perfectly into sprints and mirror programming's approach to production.

Also, to paraphrase, there is no such thing as heavy or lean documentation, only the right documentation. Every UX professional I've spoken to about agile produces the documentation they believe the team or their stakeholders need. No one I've talked to is creating 60 page specs because they want to create 60 page specs.

If developers get a 60 page spec, it's most likely because someone somewhere feels they need it. (And this is usually the UX professional.)

This ties in with design/UX literacy. The more literate the team is, the more lean the documentation can be. This is part of the reason agile works better with experienced team members who are familiar with each other. The greater intimacy you share because of experience in the field and experience with each other means you can say less and mean more.




* That is not to say that the vision and strategy is immutable. On the contrary, the evaluative testing done during agile lifecycles should constantly examine the vision and strategy and constantly adjust and change it as necessary. However, you cannot start sprint 0 or spring 1 without *some* vision and *some* strategy.

Comment by Jason Furnell on September 28, 2009 at 10:09pm

Austin,

"UX is not the barrier. Bullshit is the barrier." - it leaves me both unsure how to response, but also very inspired to respond :)

so two things....

1 - the transformation i was thinking about is one away from UX'ers as Design Dictators who "own" documents and hand over deliverable to one where UX'ers are Design Facilitators who don't in fact own any assets other than the knowledge that they played a key role in guiding a project towards delivering a well crafted user centered piece of live working software..... its a confronting change if your a "designer" who wants to design portfolio pieces.

2 - that the balance between upfront vision strategy effort and running a truly agile "development" process is hard to find. Anything you do upfront falls into the "isolated upfront requirements" bucket, but as soon as your in the build cycle finding time to ask the hard strategy and vision questions can be difficult.

Interested to here how people get this balance right... or have I fallen into the bullshit trap again.

J

Comment by Austin Govella on October 7, 2009 at 1:24am

"...away from UX'ers as Design Dictators who "own" documents and hand over deliverable to one where UX'ers are Design Facilitators who don't in fact own any assets other than the knowledge that they played a key role..."

In my experience, I know no designers who not consider themselves more facilitators than owners. Maybe we survey designers AND engineers AND product managers to examine whether designers act like and/or think they own more than they facilitate.

"isolated upfront requirements"

Is this a bad thing? What are "isolated upfront requirements"? Why are they bad? Are they always bad?

Comment by Mike on October 8, 2009 at 5:20pm

UX designers are encouraged to become facilitators rather than "dictators" because Agile is fundamentally about giving more autonomy and decision-making power to developers. There's a lot of rhetoric about democracy, but in practice, if you are in marketing, sales, support, UX or product management and aren't contributing code, you are shut out of the process, just like in open source software.

Agile ends up concentrating power in the hands of the developers, and I think we might risk the hypothesis that this is actually intentional. Formal roles and responsibilities are rejected, but taking their place is a process that implicitly privileges developers at the expense of everyone else. Sometimes this can be a good thing, but often it's not.

UX processes tend to have at their root, the assumption that the broadest possible perspective is the one that should have the power, the one that can best synthesize into a coherent whole the many perspectives in a company, varying disciplines, skillsets and types of users. I've yet to be convinced that this is wrong and that Agile is better.

Comment by Billie Mandel on October 8, 2009 at 5:30pm

As far as I'm concerned, not only the UX person but everyone on the team has to shift from Dictator --> Facilitator model for agile to work well (or for any product development effort to work well, if I think about it). A good team is like the Justice League, right? We each have our own superpowers, and we collaborate swiftly and effectively, each one using our strength for the Greater Good. I think each member of the team has to understand what each other's powers are and how they're best used (guess that means I'm coming down more in the "roles" camp than in the "literacy" camp).

Re: "isolated upfront requirements" - maybe it's only the "isolated" part that's universally bad. I see upfront requirements as the "why" that should overarch everything a team is doing, even if the details of "what" and "how" change through a dev cycle. I think that if the "why" is determined in isolation and pitched over the wall, it's likely to have the same effect as if any other core aspect of a product is done in isolation and pitched over the wall (misinterpretation, obstacles to cooperation, overall bad mojo).

Re: "design dictators," I'm with Austin - maybe I'm just extra-lucky, but I don't know many in real life, though the mythical ones often get lots of attention in community debate. If the UX field continues to require portfolios for folks to get jobs, there's no reason a designer can't create a "portfolio piece" post-project to show what their contributions were and what the end result of the team's collaboration was. (Same as customer documentation - get it done well, document it properly at the end where needed)

Comment by Eva Kaniasty on October 9, 2009 at 2:07pm

I haven't worked in a strict Scrum environment, but my team has been trying to follow the Agile philosophy (i.e. shorter releases, phased implementation, less documentation, etc) for a few months now. And so far, I love it, for 4 key reasons:

1) It forces UX to work (and talk) with developers much more closely
2) It makes it more likely that usability improvements are actually implemented rather than wasting away buried in some report
3) It works very well with iterative usability testing
4) It makes it much easier to adjust mid-stride to changing requirements

I think research is a separate activity that should not be scheduled into the sprints, but rather happen before and in parallel and then feed into the release schedule. Making sure that a company allocates time/resources for research is a challenge that's not exclusive to Agile anyway...

Comment by Liam Friedland on October 30, 2009 at 8:13pm

What I’ve come to believe through repeated exposure to Agile development projects is that Agile development must be proceeded by some iterations of Agile requirements and design. This work needs to happen BEFORE the hard-core production coding begins. Prototyping during the requirements and design phase is OK, but trying to create production code and test it is a mistake during this phase.

I don’t believe you need a lot of these requirement/design iterations before coding starts. You just need to ensure that you’ve:

1. Got the high-level requirements right
2. Defined the big pieces of your product’s information architecture, navigation model, and the key surfaces
3. Validated the design concepts with users

Once the big picture is reasonably defined; the traditional, synchronous work of Agile development can begin. Using this approach allows the design details to plug into the larger design architecture more easily and rationally.

I know the big deal with Agile is that design, implementation, testing, etc. are all supposed to proceed in parallel. But IMO this is a very immature perspective on requirements and design. After all, Agile was created by software developers, not designers. We designers need to take ownership and responsibility for Agile methodology evolution and not just accept a sub-optimal process that is handed to us.

Billie: The Justice League / Superpowers metaphors were great!

Comment