Loading ...
Sorry, an error occurred while loading the content.

The customer is always right

Expand Messages
  • Phlip
    AU: Right? Suppose the customer asks you to make the main window un-resizable. Make its geometry static and repress the grab handles on its window frame. Maybe
    Message 1 of 49 , Jul 15, 2005
    • 0 Attachment
      AU:

      Right?

      Suppose the customer asks you to make the main window un-resizable.
      Make its geometry static and repress the grab handles on its window
      frame.

      Maybe the customer (a marketing department) thinks they target the
      RealPlayer / Windows Media / Musicmatch Jukebox theme, where a
      user-friendly software program impersonates a user-hostile hardware
      gadget. These rock-n-roll skins are indeed resizeable, but the
      customer doesn't realize that. They want the chic, even if your
      program has lots of business data to display in grids that should
      resize.

      Agile theory says you code directly to the immediate requirement, and
      deliver the request. This increases the odds marketing can ship your
      product, and they can relax their Illusion of Control and allow actual
      usability leadership (from the end users and, natch, from you) to take
      over.

      Right?

      --
      Phlip
      http://www.c2.com/cgi/wiki?ZeekLand
    • grahamastles
      ... Having a separate UCD process also interferes with one of the core benefits of Agile development: Continuous Scope Management. In my experience the worst
      Message 49 of 49 , Jul 26, 2005
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@q...>
        wrote:
        > [snip]
        > This, I think, is why I worry when the stock answer to integrating
        > UCD into agile practices is that the UCD person sits in the
        > customer role.
        >
        > It becomes harder for the developers to get to grips with the
        > stories because they're out of the loop when it comes to the design
        > decisions that helped shape those stories. It also seems to
        > encourage more up-front design than I think is necessary in an agile
        > environment.
        > [snip]

        Having a separate UCD process also interferes with one of the core
        benefits of Agile development: Continuous Scope Management. In my
        experience the worst result of big up-front design is that it produces
        product bloat and creates expensive, monster applications of which
        major portions are not used. More importantly, it delays user
        feedback from working software that can guide the development team to
        producing the highest-value portions as quickly as possible.

        The key tool to avoid this is to get the whole team working on finding
        simple implementations that meet the essential business objectives.
        That is what splitting cards is all about: Look for the 20% subset of
        the card that gets the essential business value, split it out to an
        early card, and get as much basic functionality into the users' hands
        as quickly as possible. This accelerates the feedback loop and
        permits prioritizing the remaining cards based on business and user
        feedback.

        Take the old XP mantra: Do the simplest thing that can possibly work.
        Add to it: defer the rest to another iteration.
        and make sure that the "customer" understands the basis for
        prioritizing the cards, and this will accelerate delivery.

        Graham Astles
        gastles (at) projectcards (dot) com
        http://www.projectcards.com
      Your message has been successfully submitted and would be delivered to recipients shortly.