Does it Really Work?

Last week during TW London Last Thursday event, I had the pleasure to see this presentation from Dave Robertson and John Johnston (or at least part of it), about how Agile and User Centered design are more a match, sharing goals and values, than different approaches to software development.

If you have some time you should really watch it, it is worth the time.

The overall presentation is really good, but the reason I’m posting here is one specific point that was mentioned, which I believe really hit the spot, and that’s when they say we should rethink the word work in the “the simplest thing that could possibly work” sentence.

This point goes back to the Agile Vs Usability discussion and it is very correct IMO, because it reiterates that development teams should not deliver any code just because it was quick to develop it and the client is happy (although he shouldn’t be at all) since it didn’t cost a fortune.

And what is interesting about this subject is how agile teams don’t usually accept low quality code standards (code without tests, lots of hacks, etc..), but easily accept low usability standards, not understanding that is also their responsibility to define what a good user experience is.

What I’m NOT trying to say is that the user should be left outside from the application design. He should definitely have his opinion (and a strong one), but should also receive advice in UX standards as much as he should in code quality, making sure that he understands what he loses when is trying to save money on each particular feature.

  1. Given that Agile software development is constantly allowing for users to test and comment on the system, before it is handed over at the end of a traditional waterfall project, how is the user considered left out?
    The useability isn’t at the end of the day, up to the developers. If the customer is not happy with it, they will being it up at the end of the iteration and this can be resolved.
    Maybe I am missing the point of the post?


  2. @David,

    it depends if the customer knows how to evaluate usability, and my point is exactly that this isn’t always true (and its is not his/her job to do it anyway).

    If you say to the customer “Let’s stop testing, it will make us go faster”, he won’t have a clue either, but traditionally in Agile testing is considered very important and under the team’s responsibility, but UX not.

    Carlos gives a really simple example in this post (, which I have seen happening in projects, that is delivering lists without search or pagination.

    The customer is very happy and cheerful, until he has a lot of data in his system and can’t find anything anymore, but then it is too late to complain about it.


  3. anton said:

    I think the the truth is in the middle: the testers should be almost customer and in the same time with technical experience

%d bloggers like this: