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