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…

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…

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.

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).

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.

Best,
Tom

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!

Best,
Tom

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?

Best,
Tom