What “Fail Fast” Doesn’t Mean

Agile development is a process (nay, a “culture”) that amongst other things has a number of revolutionist slogans attached to it. One of these is “fail fast” – sometimes boosted by the rejoinder “fail often”. My relationship with Agile has been a bumpy one, but I think I’m qualified to at least understand the basics of why that might be. And from a UX perspective, the “fail fast” mantra has been a particularly difficult one for me to understand when I observe it in practice in scrum culture.

Firstly, let’s be clear that what I’m referring to is an aspect of “iterative development”, not the older project management idea of being brave enough to kill off a project once you know it will fail. The Agile prescription (here over-simplifying for the sake of convenience) is to embrace failure as a way of getting to your goal. You therefore should eschew any activity such as laborious documentation, or “big design up front”, that prevents you from getting things out of the door to see if they work. And if they don’t work, you learn from that mistake and try again until, eventually, you will achieve what you want.

Perhaps the best example I’ve see of this method working well in practice is the story of the Gossamer Albatross:

“The first airplane didn’t work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, retest, relearn cycle went from months and years to hours and days.”

Here, Aza Raskin gives the story a new spin (“solving the wrong problem”), but it’s clear that it’s also an iterative success story. The trouble is, and in common with most Agile proponents, Raskin doesn’t point out that presumably Paul MacCready, the designer of the human-powered plane, felt that each of his iterations were the best he could do at the time. Only through the disappointment of failure could the truth be revealed, but until then, I assume he truly believed they would succeed.

But what I see when I look at Agile development, where it relates to user experience, is a very different situation. The mantra of “fail fast” is essentially an excuse to produce shoddy work which can always be fixed later. But somehow it never gets fixed because of fail fast’s evil twin “be good enough”. What matters is that something shipped on time, and that now it’s being exposed to the real world of pass or fail.

This is obviously a huge misinterpretation of the “fail fast” principle. If you know your design is poor and needs improving to meet your goals, why not do it right the first time? The answer is that it delivers the illusion of speedy development, and is a devious way of buying you time. As my colleague Ty Yamaguchi says “Do it nice, or do it thrice.”*

I don’t know whether designing a human-powered aeroplane is any easier than designing an iPhone application (of any note, of which there are incredibly few), but where human factors are involved, things get mighty complicated very quickly. I’d love to see a UX practitioner working in a scrum team delivering designs at each sprint that they truly believed in. I don’t think I’ve experienced that though. Perhaps I’d better try again until I do.

* This refers to a recent project given a crazy deadline, which naturally produced a disaster (strike one). The disaster had to be fixed before shipping (strike two), and now we’re going back to re-design it all over again (strike three).