in Agile, UX Practice

Notes from the Agile UX Retreat at Cooper

This last weekend, a group of about 30 UX designers, developers, and leading thinkers in the Agile UX space (Jeff Patton, Ward Cunningham, Alan Cooper, Lane Halley, Desiree Sy, and William Pietri among others) met at Cooper in San Francisco to talk about the power and the challenges of integrating the Agile and UX disciplines.

Photos by Chris Nodder.

Not surprisingly, there were a wide range of opinions.  More surprisingly, for such a large group, we were able to keep our discussion focused and productive.  These are some of the big take-aways that stood out in my mind.

The Us/Them Challenge

We intentionally had attendees with a mix of backgrounds, including UX designers, developers, testers, and managers.  A consistent theme throughout the event was that of the Us/Them challenge, of how the separation of work among team members is a fundamentally negative force working against the project’s chances of success, and goes to the core of why traditional waterfall methods so commonly fail.  That separation, be it via role-based silos, throwing work over fences created by phases of work, or the underlying mentality that What I Do Is Different From What You Do, is the source of the Us/Them camps within teams and the havoc they create.  Agile, in contrast, seeks to minimize the Them and maximize the Us, not just through focusing on distributed knowledge, but also on distributed understanding and empathy for other team members.

We tussled over the issue of how much work UX designers should be doing on their own, how much work they should be doing up front before involving developers, and ended up rallying around the cause of the barely sufficient Iteration Zero, of doing the absolute minimum separately from other team members throughout the project.  And when Us/Them thinking would creep into our discussion, such as when a UX designer started talking about the importance of alone time, someone else would call out “Us/Them, Us/Them!” as a kind of mantra of the event.

What is the relationship between UX and the Agile team?

We had a lot of interesting discussion re. where UX fits into, or what its relationship is, to the Agile team.  The idea that UX should be more a competency and less a role resonated strongly. Alan likened the software team to a sports team on a field, in which everyone has set roles but their actual work can be fluid across the field/project. We also discussed the role of the UX Developer, a prototyping competency dedicated specifically to simulating User Experience, as a powerful pattern in Agile UX – at least two of those attending were from organizations that had independently adopted this practice.

Toward a Post-Agile Paradigm

But perhaps the most interesting take-away from this event was that there was a strong feeling among us that we are moving toward (or have already entered) a Post-Agile Paradigm, meaning that what we really are talking about here is not the Agile your grandparents knew and loved, er, I mean the Agile which the original signatories (of which one of them, Ward, was attending) articulated in 2001.  Remember, Agile in its original form is largely silent about UX.  Our conversation was about a paradigm in which the voice of UX plays an equal role in the project chorus.

Here are a some nugget quotes from the event:

Proccesses that are able to embrace the unexpected will look sloppy to the outsider. -Ward Cunningham

The only products that are really done are the ones that die. – Jeff Patton

If you work really hard to please your customer you will most likely fail. If you work really hard to please your user you will most likely succeed. -Alan Cooper

Iteration Zero is about paying down strategic debt. -Desiree Sy

Product ownership is a team effort. -[Don’t recall who said that]

At the end of the event, Lane was leading us through a root-cause analysis, to help us drill down into specific causes and corresponding actions we might take.  We actually were not able to quite finish this exercise before we ran out of time, which sort of left us with a kind of cliff-hanger motivating us to organize a follow-on event, which I very much hope we can do in the near future.

Also, other attendees have posted links to their blog posts about the event at the Agile Experience Design social network.

Thanks to the following companies who made this event possible!

Atomic Object, Cooper, HP, Pivotal Labs, and TechSmith.

  1. Hi Anders,
    I just joined an Agile team and I had to work hard to convince management that it would be better to work with graphic designers rather than try to train the coders to become graphic designers themselves. I also see a lot of job postings asking for a designer/usability/coder, hence my worry. There are extremely few people who can master everything.
    Pairing specialists is a much better idea. Although it’s not really a pair, but rather a small team. A website needs at least business strategy, IA, user research, graphic design, copywriting and code. It’s more a little family :)

  2. Hi Sylvie – thanks for your comments. I’m not sure I would agree with that Agile insists on team members being Jacks of all trades. Agile isn’t really concerned with how many hats any one team member is able to wear. What matters more is how those team members inter-relate. Say, for example, I have a genius visual designer and a genius developer. The visual designer knows very little about coding and the developer knows very little about visual design. In an Agile model, that is ok, because if they, for example, are co-located or maybe even pairing cross-functionally, i.e. sitting side by side and working on creating a design solution to the same design problem at the same time, then they can cross-pollinate their knowledge. The developer can look at the problem from the coding dimension. The visual designer can look at the problem from the visual design dimension. By virtue of their conversation, they can have a rapid exchange of ideas and develop a design that is cross-dimensional, i.e. a whole design.

    Interestingly, if they continue to work this way, i.e. pair, then the developer will begin to learn more about visual design and the designer more about coding and they will eventually become Jacks of another trade…

  3. I remember my early days as a webmaster 13 years ago. At that time, the young web industry was mainly composed of generalists who would do graphic design, coding, IA, copy, etc. Then specific competences began to emerge. It became pretty clear that one guy was better at graphic design, another one at coding, yet another at copywriting… And we all quickly realized that the product quality was much better if we put together a team of experts who were not interchangeable.

    It takes time to be really good at something, Malcolm Gladwell is right about the 10,000h or so. You cannot be the best graphic designer, the best user researcher and the best programmer. That is simply not doable. Mastering all these skills takes time.

    In my 13 years career, the successful projects I worked on always relied on a team of experts working together. Generalists are bound to be weak in some areas and as a result they tend to cut corners. And the product quality suffers.

    To me, the insistence of Agile to hire Jack of all trades is just business pressure. Interchangeable resources who can do any type of work presumably cost less, since we can get everyone busy no matter what the tasks are. It’s better than having a designer just sit there because there’s no design work for him at the moment. If the guy can code and do usability tests and make great cappuccinos, it’s better!

    I seriously doubt the claim that it makes better products though. I’ve been on 100s of web projects and all my experience points to relying on specialists. Getting them to collaborate is not always easy, but as someone said, it’s those debates made of having different perspectives on the product that bring it to the next level.

  4. Hi Anders,

    Thanks for the report about the event. Sounds very interesting!

    I would perhaps disagree a bit with the analogy. Consider a baseball team: A position player has quite different skills and capabilities than a pitcher, for example. They are on the same team, they have the same goal (victory without injury), and they are managed by a coach (hence Agile’s use of the term).

    Yet a pitcher would not likely be a leadoff hitter, nor would a center-fielder easily pitch for middle relief. Could a bullpen catcher play right field in a playoff game? Possible, but again not likely.

    In the same way, a person whose skills are centered in understanding and empathizing with people does not likely have the same skills as a person who easily codes Ruby on Rails or defines data architecture. Yes, each person needs to communicate intent, requirements, and capabilities, in the same way that a baseball team sometimes congregates on the mound to determine specific situation’s (read: scrum?) or inning’s approach. Yet a 2nd baseman trains as a second baseman and is expected to work as a second baseman: great glove, so-so bat, no pitching.

    A programmer can analyze user behavior as well as an interaction designer can refactor code. In individual cases, this might happen…but only in the sense that the Cubbies might win the World Series (barely possible but highly unlikely).

  5. Hi, once more, Anders,

    I’ve read a bit more around the Web and can only conclude that I may have “jumped the gun”, somewhat, here with my complaint. Although I must say, I’m also still a tad confused — on the one hand you have a book coming out soon that is specifically for UX professionals who may want to integrate themselves into Agile teams (very much looking forward to reading that!) – and, clearly, from the guest list at this gathering, alone, you have a deep familarity with Agile methods… So, I guess what I was keying off was the analogy I’ve seen you use a couple of places (and here) about the baseball team being able to freely substitute between positions being like an Agile development team with developers and UX designers.

    Now, I took that to mean that everybody should be able to “play all positions” — was I simply over-extending your analogy somehow?

    OK, well I feel as though I should have hung back a bit until I had a more nuanced understanding of what you were trying to say, but I was in the throes of the topic and really enjoying something juicy to engage with (there hasn’t been much Agile + UX talk around these parts for the longest of times!).

    I’ll still be interested to hear if you make anything of the points I was shooting for — are we really talking orthogonal vectors with respect to what you are proposing? Hope not.


  6. Hi, again, Anders,

    I guess my first message was aimed at the discussion of “role vs competency” in terms of how one thinks of UX in an Agile team. Just now, in re-reading your post, I realized that I also wanted to comment on the “us v. them” problem — and that the two are related.

    You seem to be saying that the way to deal with the tension between the roles is to eliminate them as separate entities — but I’d like to put forward the idea that there are “valuable tensions” on a team and it’s always been my sense that Agile doesn’t try to eliminate the struggle between say, the sponsor and the developers, so much as greatly reduce it in magnitude to the point that it is manageable and even productive — by, for example: 1) shortening the cycles of specification/production/evaluation and 2) giving each role its own logical non-overlapping control points to keep it secure.

    By doing 1), the disappointments and misunderstandings that are inevitable in such complex work are reduced to a level that can be managed and turned into a gentle course-correction, rather than a violent falling out with its attendant political maneuvering and felt need to stone-wall, etc that can all-too-easily occur in projects of this sort. Further, by allowing for 2) each party is empowered where it makes sense — business in planning, developers in estimating — and not tempted to make underhanded strategic moves in the sort of ugly game of “musical chairs” that sometimes takes hold when roles and control points are not so well distributed.

    So, if you buy this model of Agile — that it doesn’t eliminate tensions, but merely mitigates them to everyone’s ultimate benefit — might it not be possible to do the same with the UX role? This then wraps around to what I was talking about in my first post — why I think keeping it as a distinct role is valuable — but also is trying to say that “us v. them” is not necessarily a bad thing in the context of a well-designed methodology. Then the question becomes one of how to insert UX in the process with the right kind of structure and appropriate control points so that it can contribute without doing violence to the team harmony and over-all project progress. I think it’s possible, but I’ve rambled on a bit, to this point, and should probably wait to see how adamantly you disagree with my analysis, so far, before I launch into that arena ;).

    Fascinating topic. Thanks for providing a sense of the discussion at this gathering and the opportunity to comment!


  7. Hi Anders,

    I’m not sure I understand why you would want to insist that UX and Coding team members need to be interchangeable, any more than you would insist on the same with respect to Graphic Designers. Or, do you expect excellent programmers to also be able to play that role?

    All three of these areas strike me as having distinctly different ways of perceiving, organizing and moving through the world. Of course, talents in any combination of these areas may *happen* to be present in the same individual, but *insisting on it* as a prerequisite for team membership, seems to add an odd and potentiallly deliterious obstacle to the whole process. To my mind (and based on my project experience) keeping the concern for the human-psychological and machine-formally-logical spheres in seperate heads on a project is actually a better (not just a probably necessary) way to organize the work of software development. It brings some important (what I would argue are) inherent tensions to the surface and forces them out in the open space of conversation, so that priorities can be maintained and compromises clearly noted.

    It’s great to hear that a place for UX practitioners is being actively pursued in the Agile cosmos. I just think it would be a mistake to try to reduce it to another set of procedures for the programmers to attend to… rather than recognizing it as a talent in the social/psychological realm, the way wicked good coding is in the logical one.

    Are you completely convinced that this is not the case?


  8. Hi Rotkapchen – not sure what you mean here. How is the commitment to architecture missing and what does that have to do with Agile? One of the biggest problems with traditional software development methods has been the reliance on engineering metaphors, such as “Software Engineering” or “UX Architect,” which imply that creating a software product can be approached similarly to the creation of a physical structure or machine, such as a building or airplane. This has failed miserably, and has been one of the fundamental driving forces in propelling the Agile movement into the mainstream. While engineering projects work with (relatively) stable research data (e.g. the geological research done when building a bridge is unlikely to change any time soon) and communication standards (e.g. building drawings use age-old building codes), software is a high-change, high-novelty domain, more akin to a theater production. In other words, I feel like your comments seem to be an example of old thinking applied to a new paradigm.

  9. Well you might as well throw out the role because even the practitioners are missing a critical element: it’s User Experience ARCHITECT. It’s the commitment to Architecture that’s missing and the corollaries to what happens in development being akin to the sub-contracting trades in commercial construction — which is a phase that happens after ALL the architects work on the designs.

Comments are closed.


  • Grand Rapids Agile UX Retreat | Atomic Spin February 4, 2010

    […] company owners, consultants, and employees. Approximately half of us had participated in the first retreat, and half of us were new to the group. I felt we had a great balance between new and old, and a […]

  • Quora February 4, 2010

    Is there any other design methodologies beside user-center design?…

    Two variations that immediately come to mind, remember both really come more from the HCI field than from traditional design disciplines like architecture or industrial design, but nonetheless, Activity Centered Design, first introduced in an article i…

  • Aaron Johnson – Links: 6-8-2010 February 4, 2010

    […] Notes from the Agile UX Retreat at Cooper – Anders Quote: "… The idea that UX should be more a competency and less a role resonated strongly. Alan likened the software team to a sports team on a field, in which everyone has set roles but their actual work can be fluid across the field/project." (categories: ui ux agile softwareengineering software design ) […]

  • SQL Server Modeling, LINQ to M and AndAnd « Tales from a Trading Desk February 4, 2010

    […] from the Agile UX Retreat at Cooper Possibly related posts: (automatically generated)It’s SQL Server Modeling […]