Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Wednesday, July 26, 2006

Is Agile Development Killing Usability?

Does the agile software development mantra of "Do the simplest thing that could possibly work" lead to functional, but unremarkable software?

In this article on Wired, the author raves about Apple's attention to detail in something as small as a Date column changing its format when it's resized.

While I was adjusting the width of the columns, I noticed that the date changes format depending on the width of the column. If the column is wide, the date is displayed as "February 27, 2006." But if you narrow the column, the date changes to a shorter format: "Feb 27, 2006." If you narrow the column even further, the date format changes to the shortest format possible: "2/27/06."

In one sense, agile development approaches have nothing to say about this level of usability or "delight", as this is something the customer or "product owner" needs to specify and prioritize. So a customer that values the little details that make users squeal in delight would be wise to consider those as priorities, assuming they aren't too costly.

But in a more philosophical sense, since agile development promotes frequent delivery, and ruthless prioritization, your team will quickly be forced to make choices about what its true goals are. For commercial software, little touches can be critical to building loyal users, but it's the big features that get most of the attention. Internal software will often make do without the bells and whistles in exchange for more features, since their users are somewhat captive.

It does seem, though, that agile teams will be less likely to either prioritize or implement some of the more subtle touches of the kind that the Wired article discusses. When forced to choose between the features "Send email", and "Implement graceful date column resizing", guess which one is likely to get short shrift.

To offset this effect, I think it's important when working on a project to be very clear up front what the team values. If "user delight" is a priority, it needs to become infused into the team psyche. Developers, designers, testers, and the rest of the team need to be aware that any idea that can benefit the user experience is worth writing down for future consideration. Every decision needs to be made in the context of "How will this benefit or detract from the user experience?"

Ultimately it will be the customer/product owner that makes decisions about what should go in the software and when, but with the whole team focused on adding value to the user, many more opportunities for small wins will be uncovered.

Agile development is an ideal way to get quick feedback on these kinds of subtle features with its emphasis on frequent releases. But you may need to guard against the complacency around user experience that's often expressed as "If the user didn't ask for it, they obviously don't need it."

It's our job as software designers and developers to see beyond what is asked for to what is truly needed. And sometimes we have to go beyond need, and find joy.

There's nothing more satisfying to me in the field of software than a truly delighted user. It's hard to put a price on that.

For more on agile tools and techniques:
(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • I have to admit, as somebody who sometimes wears a usability hat and has worked with some agile teams, I have the opposite experience.

    Because you are releasing regularly, and are getting feedback quickly, you are more likely to find and prioritise usability related stories than non-agile groups.

    Agile teams are a lot less isolated from the end-user than non-agile groups... and that means their problems get pushed to the top of the priority list more often.

    By Blogger adrianh, at 12:48 AM  

  • I agree with adrianh. And it is also important to remember that part of agile is not to start with feature bloat, but start by covering the basics and adding as testing and feedback require.

    By Anonymous Anonymous, at 10:14 PM  

  • [Cross-posted from digg comments]

    In my opinion, the agile team is more likely to create well-tested remarkable software that has those special little touches than a traditional development team.

    If you are working from a 45 page requirements document that was written up a year-and-a-half ago, it is not likely to mention a detail like altering the display format to match the display size. But using an agile approach, your on-site customer is likely to glance at a value that doesn't quite fit the column and say "Gee, it's too bad this doesn't fit", at which point the developer pipes up to say: "Oh, we could change the format if you wanted. Thanks to the refactoring I did two weeks ago, there's a single routine that selects the display format so it would be easy enough to add a check for it. What formats would you like?".

    That never happens in waterfall development.

    By Blogger Michael Chermside, at 10:23 AM  

  • Thanks for the comments.

    I agree that by using Agile methods, you'd *expect* to find and implement more usability-related features (assuming that's important to the customer). I just haven't seen it play out that way in my own experiences.

    One possible explanation is that when there are so many more visible decisions to make due to closer collaboration, the customers are less able to focus on small UI details.

    I'm not sure it's an "agile" problem, and I wouldn't say that this has been more of a problem than with non-agile teams, but I haven't seen evidence that agility actually makes this problem better.

    It may just be that having individuals that are really good at identifying and implementing "delight" features is the magic, and this could happen under any process.

    By Blogger David Churchville, at 1:03 PM  

  • You are confusing Traditanl "Waterfall-inspired" philosophy with Agile philosophy.

    Im working on an agile project and usablitiy is much more explicit in agile since the story could and often is "Make that GUI better" or "Move that button a litte bit up" or "Darken the color of that panel" or simply "Colors choices are bad, change them to good ones"

    Priority should be set by the customer in agile projects.

    You are confusing technical decisions and buisiness decisions.

    Technical decisions should be done with the mantra: "Do the simplest thing that could possibly work" for the story.

    Buisiness decisions is Priority of stories

    By Anonymous Anonymous, at 3:02 PM  

  • Maybe I'm missing something, not being a programmer, but I'd say an e-mail program that gracefully resizes date columns, but doesn't "send email," is seriously lacking in usability.

    By Anonymous Anonymous, at 6:42 AM  

  • Doug,

    You're absolutely right that the first order of business is building core functionality.

    Without "use", there can be no "usability".

    Really, my question is just whether the little things that make an application great will be more likely to be suggested on an agile project versus a traditional one.

    From previous posters, there's a sense that yes, agile teams will be more likely to uncover "delight" features.

    I worry that in the "Do the simplest thing" mindset, these kinds of features might be discouraged, or simply not suggested by the dev team.

    I hope to be very wrong on this, as I think Agile development is the best approach I've used or seen.

    By Blogger David Churchville, at 7:39 AM  

  • Agile tends to focus on what is on the forefront of the customers' minds, not necessarily what is most important to the customer.

    For example, I worked on a cost estimating system, developed is a semi-agile fashion. We spent over a month tweaking one screen - while the system was producing bad numbers.

    The problem was the computational errors were not obvious, but the fact that a scrollbar was showing up on the bottom of the screen was. The customers focused on what was right in front of them, and couldn't move on until it was beaten to death.

    By Anonymous Anonymous, at 3:08 PM  

Post a Comment

<< Home