Mark Gilbert's Blog

Science and technology, served light and fluffy.

"Agile Software Development and UI Design: a Match made in Heaven?"

This past week the XP West Michigan users group held their monthly meeting, and brought in Professor Robert Biddle of Carleton University in Ottawa, Canada.  Professor Biddle spoke about the research that his group has been doing on agile teams around the world.  The talk was fascinating on many levels, and Professor Biddle made a number of very interesting points.  Here is a smattering (paraphrased):

A tremendous amount of energy has been poured into developing agile teams, and describing how to be a better or “more agile” team.  However, what can be said about how to be a good customer interfacing with an agile team?

Professor Biddle made the observation that agile teams frequently find themselves hating the process after about three months.  Why?  The customer nods and goes along with the development team for that amount of time, making light comments about the direction of the project and hoping that they eventually get on the right course.  The three-month mark typically is the breaking (snapping?) point for the customer, and they finally let their frustrations out.  To avoid this, a good customer needs to have the courage to say things like “no, this isn’t what we need” or “no, we’re not there quite yet – here’s where we’re still falling short of our goals”, and they need to say these things as soon as the customer realizes them – not three months later.  For most human beings, this is a very hard thing to do.

Tell your stories.  Let everyone know where you’re coming from.

“User stories” aren’t supposed to simply be a list of requirements for the new system.  They are meant to be stories – tales that involve real people facing real problems in the real world.  One of my favorite books is “The Soul of a New Machine” by Tracy Kidder in which he tells the story of a company (Data General) working to bring a new computer to market.  The story he tells is riveting because Kidder gets you involved in the people.  He explores their past, their motivations, the circumstances that brought them together as a team, and their challenges to get a completely new machine out the door at a breakneck pace.

Granted, we aren’t all Pulitzer prize-winning authors, but the stories that we collect for a new piece of software have to be more than simply “screen 42 will collect the order shipping information”.  They need to involve the people that will be using it, their motivations, their goals, etc.  Otherwise, we’ll miss valuable information about who the system is being built for, and the other team members won’t understand where we’re coming from.

Prototype the system using paper instead of digital tools.

Professor Biddle described teams that would mock up screens using sticky notes and pens, and ask people to “interact” with the system.  The system is low-tech, inexpensive, very easy to change, and only requires a few seconds for the users to suspend their disbelief.  What’s more – and this was a point that struck many in the room, including myself, as profound – no one will mistake sticky notes for a nearly finished system.  The same can’t be said for a prototype built with a RAD suite.

Computer Science (CS) students rarely learn UI design.  Human-computer interaction (HCI) students rarely learn how to program.  This is bad.

Professor Biddle mentioned that at Carleton University the HCI curriculum was part of the Psychology Department – not the Computer Science department.  His position at the University happens to be co-listed between the two departments so he is able to pull in researchers from both.  He makes the point that not everyone needs to be experts in both disciplines, but everyone does have to be aware of what is going on around them.

The User is not always king.

I think this was my favorite example of the evening.  He alludes to the attitude on several agile teams that the user is the ultimate driving force for the direction of the development efforts, and their word is final.  After all, the software is being built for them, right?  The user is necessary and critical, but not sufficient for a good piece of software, he illustrated it with the example of an ATM being designed purely by a user:

  1. The user walks up to the machine.
  2. The machine dispenses money.
  3. Preferably not the user’s money.

Perhaps we should consider other points of view?

All in all it was a terrific presentation.

Advertisements

March 29, 2008 - Posted by | Agile

Sorry, the comment form is closed at this time.

%d bloggers like this: