User Experience and Agile – Meetup report

I used to work with a chap called James. When I met him, he was known as a User Centred Designer (UCD) , and I worked with him on some of the projects that I have previously written about on this site. We hope to collaborate on some articles on here in the future.

These days, he’s a Senior Experience Designer at New England agency, MadPow. You might have seen an article recently by two of James’ colleagues, Illustrating the Big Picture : Journeys, Experiences and Interactions.

I also used to run an agile group in Oxford, where I used to live, and we used to team up with the UX Oxford group, from time to time.

Anyway, as you can tell, I’m a big advocate of incorporating User Experience into agile projects. Ever since I became involved with the Melbourne Agile and Scrum User Group, I wanted to organise an event to discuss UX and Agile.

After a couple of false starts, the evening was held on 23 May 2012, at the Seek offices in St Kilda Rd. I announced the event on Meetup, and within a day 115 places had been snapped up, and we had around 30 people on the waiting list. So, obviously a pretty hot topic!

Peter Grierson, did a talk on general User Experience principles, with an emphasis on how UX can support shared understanding in an agile project. He shared some examples of what he’s done at variuos companies in New Zealand and Australia, most recently at REA ( Incidentally, I’m hoping to team up with Pete, for a session at LAST Conference, that has a UX focus.

You can see his presentation, and listen to his talk, in the Slideshare deck, below.

Later, we had a a panel discussion relating to the gatherings’ real world examples of Agile UX . The panel used a Fishbowl format to allow everyone to take part in the discussion, which I think worked pretty well.

Thanks very much to Simon and Amelia from Seek for helping to organise the evening, and to Seek for providing the venue and refreshments for the gathering!

Going Extreme! My first taste of agile.

AKA “Being agile without Going Agile”.

Ye olde project wiki

In 2004, I started working on a project where the lead developer said, “I’d like to use Extreme Programming“, also known as “XP”. This bemused me slightly, as it conjured up images of white water rafting, and ironing in strange places. I went along with the idea though, and I found what I could on the web. At the time, there was a lot less material out there than there is these days. In particular, I remember gleaning what I could from the Extreme Programming wiki.

This project was my first involvement in what could be called an agile project. The lead dev and I had daily 15 minute meetings, we broke up features into smaller pieces, we had a list of features (which the business ordered/prioritised), we had 2 week iterations, and we increased our shared understanding on a wiki. We also had a form of acceptance criteria for the different functions on each page of the product.

We didn’t officially call it “Agile”, we just said to the business, “We can deliver what you want more effectively if we do it like this.” Because we had framed it in this way, we didn’t need air support from upper management. The business stakeholders, didn’t have time to dislike the idea, because we just started, and began to show them results as quickly as we could, as often as we could.

I had a hybrid role in all of this. I was called the Project Manager, but in reality I functioned across a variety of roles. As well as doing “PM” stuff, I also performed Business Analyst, (sort of ) iteration manager, and Product Owner duties. I also functioned as a (kind of) user experience designer. I used a pencil and A3 sheets of paper to create paper prototypes/wireframes, which is something that I advocate to this day, as one of the best techniques to use on a project. I also went out to customers and ran test of early versions of the product.

It’s still one of the projects that I look back on most fondly. A few years later, that product got “updated”, by a different team, who switched it to a different system. This supposedly increased the features available to users, but in reality confused, and didn’t add any value for them. There was a backlash about the “improved” version, such that the company decided to roll back to the version that all of the customers liked, used, and found valuable. It remains one of my finest moments at that job!

Unfortunately, I had to go back to “Standard Operating Procedure” on my next project. I’ll tell that story in a future article, that has the working title, “Retrospective, Retrospective, Retrospective!”

Change and improvement

This podcast episode of the architecture and design show 99% Invisible from radio KALW in San Francisco appeared in my Twitter stream today via @kjscotland (Karl Scotland).

99% Invisible-30- The Blue Yarn by Roman Mars

I probably don’t have to tell you that the lean concept in software development is adapted from the automobile manufacturing industry. In this podcast episode, a really interesting case study is shown where continuous improvement by reducing “waste” was achieved at a cancer centre in Seattle by adapting the Toyota Production System to healthcare.

Here were some salient points that I thought were notable in this:

Change is hard

“When Dr Kaplan told his staff they were changing the whole way they operate…the response was not pretty…There was a lot of anger…led by the doctors of course”

Change is hard. The improvement at The Virginia Mason hospital was a multi-year project. The driver of all the improvements was the needs of the cancer patients (as well as the need to save money). However this butted against the desires of some of the doctors e.g taking away offices with good views. Changing from a doctor driven experience to more patient driven experience is hard.

A different angle

“We couldn’t conceive of it intellectually until we saw it visually”.

People think they are dealing with an issue intellectually but until they see the situation represented in a different way…using a blue ball of string and a map of the hospital in this example, they might not be able to see where improvements can be made.

Using a different approach identified that waste existed in the form of patients having to wait a lot but until a different approach was…no one identified this. It was just the way things had always been done.

Sometimes people need a kick start. In general, people don’t really like being told what to do, although IMO there are times when this needs to happen but that’s the subject of another post. Helping see issues for themselves allows them to then work with you and their colleagues to solve them.


“If you’re anything like me when you hear the phrase ‘management system’ part of your brain begins to shut down. Another part of your brain prepares itself for hearing either a load of complete nonsense or common sense tarted up with unnecessary jargon”

In many walks of life, issues can be over complicated by the use of  jargon. Speaking in plain language is preferable; be careful about introducing terms like “sensei” or “Scrum Master” for example. Providing some terms as a framework can be useful but you have to be careful about them getting in the way.

Effort = Results

Putting in the effort to change yields results, despite the difficulties. In this example, it saved money by making the hospital safer and by eliminating waste and (presumably) helped the cancer sufferers themselves, improving the clinical experience by considering their needs as a priority. User Experience design for healthcare.

Further reading

There is a book about the Virginia Mason experience called Transforming Health Care: Virginia Mason Medical Center’s Pursuit of the Perfect Patient Experience

Amazon page

Publisher page

Here is a review of the first 3 chapters over at The Lean Blog

Lean Blog review

I haven’t read the book but it’s definitely on my “To Read” list.

The 99% Invisible podcast seems pretty good. I’ve subscribed on iTunes and it’s also available on Soundcloud.