Agile and UX are “an abusive relationship” - James O’Brien at UX People

Last week Kings Place hosted UX People, organised by Zebra People. Here are my notes from one of the sessions...

James O’Brien was talking to the UX People crowd about the perennial problem of the relationship between agile development and UX practice - a relationship defined by the obvious tension between the two created by one of them insisting on “no big design” up front.

His argument was under-pinned by two key points that all UXers need to recognise. Firstly, agile has been with us for a decade, and it isn’t going away. It is moving from being a way to develop software, to the way to develop software. And secondly, as James put it, “change is an inevitability in software development.” We need to accept that and make sure that our working practices and deliverables can cope with that inevitably.

James also wanted to address a couple of myths. “The fact that software projects go wrong is not the fault of agile” he said. Projects just sometimes go wrong. But he also wanted to stress that the idea that products and design could be defined in iterations was untrue.

For a start, the relationship between design and programming is “orthogonal”. It can take seconds to design a feature that will take weeks to develop, or weeks to agonise over a piece of UI that can be achieved with two lines of code. In the traditional model of designing one sprint ahead, by the time of the last iteration the UX team ought to be, according to James, “having a fucking party”, but somehow that party never happens. This is because, he argued, the relationship between design and development in agile is “an abusive one” if design slips even slightly. As I always like to think of it, a team of developers can write code at lot faster than I can draw what they are supposed to be building, once they have a head start.

The real myth James wanted to get at though, I felt, was that agile means there is no planning. In fact, James argued that the business analyst was the UX person’s best friend, because, basically, if you steer them correctly, they will do half your work for you during the planning stage before you reach iteration one.

James recommended that UX lie, cheat and steal to cope with being in an agile environment. His examples included lying about what something was called - i.e. a paper prototyping session could be described as a “UX spike”. Or cheating by making sure that test data is specifically designed to stress the UI and reveal flaws that have to be fixed. Or stealing concepts from agile, like using the phrase “UX debt” to describe sub-optimal solutions that have been deployed as “good enough”, but which need to be re-addressed in later iterations.

He also grudgingly admitted that we need to do some work, and do better deliverables that were easier to update. He stressed that we should make our deliverables easy to “refactor”. That means using smart objects, sensible layer names and conventions, and using code rather than images to show what we are trying to design. James said: “The web is not discrete states or pages, it is a series of live modules on a canvas. We can’t design at the page level anymore.”

There were two final points I thought worth pulling out from James O’Brien’s talk. Agile strives to automate testing, which makes testing users a horrible messy thing that the developers would rather avoid - so use the showcase environment to do guerilla testing iteration by iteration if you possibly can. He also said that UXers should try and make themselves continuously available to their development team. It might mean you can’t listen to music at work any more, because having your headphones on is shorthand for a massive “Fuck you I’m busy”, but it should mean you end up contributing to better products.

James recommended looking at Hannah Donovan’s presentation “Telling stories through design”, and Jan Srutek’s talk “Communicating and selling UX design deliverables”. James O’Brien’s own presentation is available online “Agile UX – How to do Design Up Front when you're not allowed to do Big Design Up Front”.

Next...

In my next set of notes from UX People, I’ll be writing about John-Henry Barac’s fascinating talk about his design journey from print to pixels.