user experience

Guess who? (Kill the Agile Buddha)

Guess who am I now.

I’m in a supermarket, I’m pushing a trolley. I’m putting items into it. I just need some bread and I’ll be going to the checkout. Who am I?
I’m in a bank, queueing up in front a machine for depositing cheques. I’ve got a couple of cheques I need to pay in. Who am I?
I’m in an electronics store. I want a new printer but I’m not sure what’s the best for me, I’m looking for someone to help me. Who am I?

Or maybe what am I?

I am a customer.

Aren’t I?

Business language backs up my assumption. The employee at the supermarket checkout is called a Customer Service Rep, my personal (customer) details are held in the banks Customer Relationship Management system, in the electronics store I’m looking for Customer Support. And after I’ve bought my printer I’ll be asked to complete a Customer Satisfaction Survey.

So everything indicates that I am a customer. Or that is what I thought I was.

Apparently not according to the Scrum zealots.

At Agile 2009 Tom Illmensee presented a paper “5 Users Every Friday: A Case Study in Applied Research”. It describes how an eCommerce division of an electronics retailers introduced agile and how the user experience team adapted to agile. It starts by describing how their initial forays into agile were deemed successful. It was collaborative with the disciplines well integrated; “whiteboard wireframes, minimal documentation, and product demos. Usability tests with paper and semi- functional prototypes were conducted with shoppers each sprint”. More than that, the whole team enjoyed the experience. A decision was made to “take agile to the next level”. The next level was the introduction of a consulting firm who brought in scrum training. The scrum dogma was painful to adopt, but they got there in the end. But there’s a line in the paper that made me angry:

“The peculiar semantics of Scrum were especially confusing at first. In retail customers were people who bought things like stereos and flat-screen TVs. Not anymore. Agile had changed the definition of perhaps the most important word in our business environment: customers were now internal product owners. Customers would now be referred to as shoppers—or users.”

I’ll write that again. Customers (the people who the business depended upon, and “the most important word in [their] business environment”) would now be called shoppers. Or users. Because in agile, customers are internal product owners.

Sorry, these consultants, these agile zealots, these software egos have got too big for their boots. Dan North, pulling to pieces the nonsense of ‘software craftsmanship’ put’s it eloquently:

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Software at the centre rather than the benefit the software is supposed to deliver. Software is the means to an end, not the end itself. If a certified scrum master (certified master based on two days training and a multiple choice questionnaire, now there’s a farce) tries to rewrite your business language, tries to tell you that your domain language is wrong, show him or her the door.

There’s a budhist saying “If you see the Buddha on the road, kill him“.

If you see agile in your workplace, kill it.

Why kill the Buddha? because the Buddha becomes an object, your own illusion of what it is. And it this illusion is wrong.  To turn the Buddha into a religious fetish is to miss the essence of what he taught. Killing the Buddha means taking responsibility for yourself.  Same with Agile; to turn agile, to turn software development into a religious fetish is to miss the point of what it is all about.

===

I presented on the customer theme a while ago, here are the slides.

And here’s me narating the slides on google video.

Test Driven Design

I recently worked with a client where one of our deliverables were wireframes that illustrated how pages would be laid out and how the UI would work.  We were quite pleased with the results, there was some quite complex AJAX based functionality that provided a really immersive, goal orientated experience that looked like it would make finding products easy and enjoyable.  Testing the initial wireframes with users was an enlightening exercise, and demonstrated that the wireframes we had developed were not yet ready – users were not able to fulfill the goals they were set.  More worrying, some of the complex functionality we were introducing just did not work (some of the navigation, filters and sorts were confusing, just presenting information on a single page would suffice).

Usability testing often gets discussed and is a good intention but all too often budgetary or time constraints mean it never happens.  The user testing I refer to here impacted neither.  We did our testing in a meeting room, the customer sitting at one end with a facilitator, and the team watching on the projection screen in the same room.  We used a talk-aloud protocol walking through the static powerpoint wireframes that were linear in their presentation according to the ‘happy path’ to realise the customer goal.  Someone took notes as we went through the wireframes (in the notes section at the bottom of the PowerPoint deck).   It was quick and dirty but produced results.  After a couple of sessions things that we, too close to the design, had missed.  Changes to the wireframes took a few hours and allowed retesting the following day.  Indeed we made some quite significant changes to the user interaction model.  When we re-tested the wireframes the improvements were evident.  The feedback was more positive; there were fewer blank faces, less confusion and “I’ve no idea what to do next” was never uttered.  This was true iterative design in cycles that took a few hours.  Compare this to the days if code was involved.

Where does this fit into the agile way of delivering software?  In the agile/ lean zealot’s passion (and impatience) delivery, and their (dogmatic?) assertion that anything but code (working software) is waste, they loose focus upon what is really important, that of overall product quality.  Product quality is not only zero/ minimal defects and meeting the business requirement, but also delivering something that is usable and delightful to use.  Developers may do Test Driven Development, but this is based on assumptions that what they will code is right.  TDD should start earlier in the process, Test Driven Design.  It takes time to write your tests up-front, but we know it to be a good thing.  So why not design the user interface (wireframes) and test that up front?

Design vision

Don’t be fooled into thinking that you don’t need to do any design when you adopt Agile.  Agile development strives to deliver business value early and often, focusing on getting working software to market as soon as possible rather than dwelling in documentation and ‘analysis paralysis’.  But let’s be clear, “business value” and “working software” are not the same thing.  You can quite easily get something into production that fails to generate revenue, decrease costs or whatever other yardstick you use for ‘value’.  What differentiates the two of them is design.  I don’t mean big up front design that details all the features and provides a concrete spec, I mean a design vision that articulates what the product goals are and a roadmap for getting there.  And what is a design vision?  A short statement of intent is a good place to start, and soon after a user interface mocked up in pen and ink.  It is cheap and easy and helps bridge the path from idea to execution.