Response: The Nature of XP

George Olsen's recent article (see Why XP and UX have Something in Common) about Extreme Programming (XP) contains a number of criticisms; many seem based on misunderstandings of XP. Such confusion about XP is both common and natural; XP is very new, and few have direct experience with it. Worse, as with anything on the rise, some people are using the label of XP to camouflage their bad practices. But I believe a well-run XP project is very different than the impression Mr Olsen gives.

One misunderstanding is the notion that XP produces prototypes. On the contrary, XP produces working software every iteration, which are generally one or two weeks in length. The initial versions of course lack features, but what is there works. As Marco Dorantes Martinez points out, calling those prototypes is like calling a 6-year-old child a prototype human.

Another is that an XP project could get to QA without any way of telling whether the built product matches what should have been built. Actually, XP requires that automated tests, specified by the customer, be developed in parallel with the software; the features for each iteration are only considered done when they pass the acceptance tests. On an XP project, QA isn't a final hurdle; it's a continuous partner.

A third mistake is the belief that XP produces no documentation. XP developers should gleefully produce any documentation the customer needs. But XP is a process driven by high-bandwidth personal communication rather than low-bandwidth documents. Documents are produced as needed, not as objects of ritual veneration.

But the largest error is that one cannot iteratively develop good user interfaces. As Mr Olsen goes on to point out, good designs are never pulled out of a hat; the feedback from prototypes is very valuable in creating a good user experience. But how much more valuable would user testing be if the prototypes were actually working software, rather than simulations of it?

This opinion is especially surprising given that he was responding to an article (Xtreme Programming makes Good Partner to User-Centred Design) which describes a PARC project that used XP and UCD in a complementary way. The UI experts were driving the process, and they felt that their end result was both much different than their initial conception and much better. As researcher Nicholas Ducheneaut said in a recent presentation at PARC, "XP expands the design space."

Happily, much of his article was more accurate. He is absolutely correct that you cannot willy-nilly release different UIs to your users every week or two. Fortunately, XP doesn't require that. Although new software is available at the end of every iteration, that doesn't mean that one must release it to end users. The difficulty of adapting to new UI should be an important input both into deciding how often to release software and in telling the developers what to build.

He is also right that the XP notion of "customer" is vague. This is intentional; XP is meant to be used across a wide spectrum of products and organizations. The "customer" is who decides what gets built, be that a single person or a committee. XP demands close communication between those who know what needs to be built and those who build it. If one of those people is a UX expert, then by all means they should be part of the "customer".

That far too many organizations ignore the user experience in building software is undeniable and regrettable. But XP is only meant to answer the question, "How do we build software?" not, "What software should we build?" Those interested in the user experience should see this not as a fault of XP but as an invitation to step in and help answer that second question.

XP, along with all of the other agile methods, is about tuning your development process so that it welcomes change rather than resisting it, about replacing theorizing with feedback. Does this mean that you should stop designing up front? Of course not. But it's a poor designer who can learn nothing from seeing their designs built and in use. Because of this, XP asserts that we should never stop designing either.

Harnessed properly, how could that fail to improve the user experience?

William Pietri
Scissor

Associated Link: Scissor

All change at the top for System Concepts
Source: System Concepts Ltd, 3 July 2009
 
Leslie Fountain has been promoted to joint Managing Director of leading usability consultancy System Concepts.

Life in UCD immortalised in fiction: you couldn't make it up
Source: UN, 2 July 2009
 
Sarah Herman's fictitious book on life in a user-centred design company has hit the shelves and The Guardian's book pages...

Interfaces Magazine - Issue 79: The Education Issue
Source: Interaction Group, 1 July 2009
 
The latest issue of Interfaces is now available as a free download from the Interaction Website.

Two new Behavioural research Tools from Noldus
Source: UN, 30 June 2009
 
Tool updates make on-site behavioural data collection easier.

Cell Phones that Listen and Learn
Source: MIT Technology Review, 29 June 2009
 
New software tracks a user's behavior by monitoring everyday sounds.

Top Six Don’ts for Usability Testing
Source: FutureNow Inc., 27 June 2009
 
Six tips for creating quality usability tests to ensure useful feedback from testers.

Usability: ‘Lovely software. But I can’t work it’
Source: FT.com, 26 June 2009
 
In a recent survey by Global Graphics, 77 per cent of office workers estimate they lose up to one hour a week because business software is difficult to use.

And what do you do?
Source: Dexo Design, 25 June 2009
 
How do you describe your job role? Here are the results of a recent 'Preferred UX/UI Title' Poll.

Most Doctors cite Usability as critical to Electronic Health Record Adoption
Source: TMCNet, 24 June 2009
 
It's all about 'meaningful use'.

Glossy monitors look good but can hurt
Source: QUT, 23 June 2009
 
A new advisory cites research which suggests high gloss monitors make users sit awkwardly.