Agile vs. Usability?

Thre’s been a recent discussion around how agile methods face usability, mainly following Jakob Nielsen’s post about how agile, if poorly executed (that’s my opinion), can be a threat to usable software.

I don’t want to say again what was already said, and I believe that agile and usability can be a good match, as long as you know what you’re doing, but what sometimes bothers me is the common thinking around agile methodologies, that usability = what the client wants. I’ll explain.

In most of the agile projects I’ve been (not to say all of them : ) ), whenever there is some issue around how to make some feature in terms of usability, like “how should be the user experience around this operation”, the common answer is: “let’s ask the client..”.

Well guess what? The client never thought about usability in his life. Of course he used computers already, but he probably doesn’t know how to better develop an application to make it more usable. And this situation gets even worst when the client is just a proxy to the real user, who will probably not even work in the application being developed.

To give a pratical example,  if you asked a bunch of people how they would like to search for web pages in the pre-Google era, how many do you think would answer a “blank page with a text field on it”?

If this ask-the-client behaviour comes from pure lazyness or some cover-your-behind strategy, that’s another discussion, but what I think most agile teams should change in the way they work is to stop pretending that the client has all the answers, and trust a little bit more in themselves to create solutions.

And my guess is that the clients would also like it, because I don’t believe they want to spend their time answering questions like “which is the best solution for this problem: a select field or radio buttons?”.

And if you really want to trust the client to tell you how to build software, do it in a real HCI fashion, observing real users using your application and getting your answers from there.

Cheers,

Francisco.

Lean Workshop at Agiles 2008

Last October me and Danilo were in Buenos Aires, Argentina, to present a Lean Workshop at Agiles 2008.

The idea came from our perception that despite being one of the main buzzwords in the agile community, Lean and its origins are still a mistery to a lot of people, specially now in the current tool age , where kanban means a card wall with some numbers on it.

The workshop aimed at introducing Lean concepts through a hands-on activity, where the participants had to build a simple lego house in this 4 step process.

• Step 1: “Buy” the Lego(TM) pieces and sort them by color
• Step 2: Sort them again by size
• Step 3: Separate the pieces required to build one house
• Step 4: Build the house and sell it

If you are wondering how that turned out in practice, you can check the video here.

In order to go through all the Lean main concepts, the activity was divided in three phases, being the process executed differently in each one: a push system in the first, pull in the second and a single person workcell in the last.

Before every phase, we introduced the concepts that were going to be applied, and after the production, a “retrospective” was held to discuss good and bad points of the process according to the participants.

This way, we could stop and explain the needed concepts between each phase, and were able to go through push vs. pull systems, waste, kanban, kaizen, and work cells, among others.

The feedback we got was very good. All the participants we spoke to later said it was easier to understand what we were talking about when they actually implemented the ideas in practice, and felt the problems that each solution had.  What also helped is that most of the participants we’re being introduced to Lean, and this was the exact kind of public we had in mind when we prepared the workshop.

After the activity, a link with software development was made, but always making clear that creating software is not producing cars, so it is much more important to understand the principles then to apply the practices.

Cheers,

Francisco