How it came about
There has been a lot of banter on the subject for a good
number of years on various SIG groups, and lots of great presentations delivered
at various conferences and published on the web that have sought to explain how
to marry the two. However there was no one go to comprehensive reference point.
I remember when I started with ThoughtWorks (agile custom
software experts) as the only UX person in Australia wishing that I could find
a definitive guide book on how to do UX in an agile environment. It is a very
different way of working but I was keenly aware that someone somewhere must
have solved the problem, and that I didn’t need to work it out for myself. The
book ended up being the book I wished that I could have read back then.
I joined forces with Marc when I moved back from Australia
to the UK and realised we were aligned in our thinking on the subject. We were
also still surprised that no one had published a book on the subject and so we
set about doing just that.
An non-movable feast
From start to finish we had FIVE months. Prior to signing
the contract I talked to
Martin Fowler and
Jez Humble,
both successful authors, about the timescales and the unanimous opinion was
that we were mad! Jez said ‘ You need at least 18 months to write the first
draft, then you need some decompression time, then you need time to rewrite and
edit.’ So we went back to the publisher, in the hope of revising the proposed
publication date. However we were faced with a ‘deal or no deal’. Marc and I
both laughed and agreed that we might as well die trying as not try at all.
A very non-agile process
In agreeing to the terms we were also asked to commit to the
length of the book. At this point all we had written was two paragraphs
describing the essence of the book. We had no idea. I flicked through a couple
of notable books on my shelf, of the ilk that I thought ours might be, stuck a
finger in the air and suggested 100,000 words. When we submitted our first
draft, it was 135,000 words long. Naively we had not appreciated that 100,000
words had been cast in stone. We then had a very tough process to cut 35,000
words (over a third of the final book) from the manuscript (and still deliver
on time).
Concurrent working
So five months is a doable time-frame, just, if you are a
full-time author perhaps. But hey, we both had full-time jobs. This is the job that
give us the experience and expertise to be able to write books. We both also
have families. So we begged borrowed and stole time and worked bloody hard for
five intense months to produce the book. We are grateful to our families in
particular who made the bulk of the sacrifices, for allowing us to realise our
ambition.
Collaborative and
feedback driven
Two aspects that were sacrificed as a result of the timeframe
was the ability to collaborate and also solicit feedback from peers and
colleagues on the work in progress. We started off with the best of intentions
and were able to include some contributions and get some feedback, but not as
much as we might have liked. If word count and time had permitted we would have
liked to have included more anecdotes and lessons learnt from other practitioners.
Test and learn
This book was only ever intended as a guide, rather than a
recipe book. It would be a contradiction in terms to say that there’s a one
size fits all approach to agile experience design. Every project will be
different because of the budget, timescales and people/process/technology
constraints.
However to stay true to the nature of agile experience
design I’m keen to hear about people’s experiences and how they have aplied,
adopted or adapted some of the concepts and ideas in the book. I promise to
share the finding and attribute them to the contributers either on the
accompanying website (if I ever get the time to add some content to it) or
perhaps even in version 2.0.
