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

'Internet addiction' linked to Depression
Source: BBC, 9 February 2010
 
There is a strong link between heavy internet use and depression, UK psychologists have said.

Could *You* be more Usable?
Source: UN, 8 February 2010
 
Bet you could.

Stowe Boyd on 'Steampunk' thinking about the Future of Computing
Source: Stowe Boyd's blog via Experientia, 6 February 2010
 
Are established metaphors of user experience holding us back from new ways of structuring our interaction through computers?

Nokia's User Experience Programme
Source: UN, 5 February 2010
 
Nokia has put together a rich and informative website covering the key elements of user experience.

Interfaces magazine: latest issue available now
Source: HCI News Service, 4 February 2010
 
The latest issue of Interfaces is now available in pdf format, free from the Interaction Website.

A Lighter Brigade of Chargers
Source: UN, 3 February 2010
 
Lots of gadgets, one charger. At last.

Mobile Touch Screens could soon Feel the Pressure
Source: MIT Technology Review, 2 February 2010
 
A quantum switch could add pressure sensing to mobile screens.

Usability, Usability, Usability: why the iPad will Succeed
Source: Econsultancy, 1 February 2010
 
The tech critics love it, hate it, love it again, shrug it off. What do usability experts say?

British Airways - at last some good news
Source: Loop11, 30 January 2010
 
In a recent website usability study for the world's leading airlines, the British Airways website proved to be the most user friendly, with Malaysia Airlines and Virgin Atlantic having the lowest user experience rating.

Computation of Emotions in Man and Machine
Source: Royal Society, 29 January 2010
 
Advances in computer technology now allow machines to recognise and express emotions, paving the way for improved human-computer and human-human communications.