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

RE: [agile-usability] RE: The customer is always right

Expand Messages
  • Desilets, Alain
    Excellent analogy. I guess what is tripping people up here can be illustrated by extending your analogy just a bit: Instead of dealing directly with the
    Message 1 of 49 , Jul 21, 2005
    • 0 Attachment
      Excellent analogy. I guess what is tripping people
      up here can be illustrated by extending your analogy
      just a bit: Instead of dealing directly with the
      architect you have somebody representing you. You say
      you want a fairly "open" house. That representative
      portrays that to the architect (incorrectly) that you
      want an "open-space" house, taking things further than
      you had intended. Now, this architect, who has been
      around for a while, is questioning if that is really
      what you would want.

      -- Alain:
      Like I said in an earlier post, it is the duty of the UCD person (or in
      this case Architect) to question customer requests if they seem wrong.
      This is especially true if the UCD person (Architect) is not talking
      directly to the customer, but is going through an intermediary. In a
      case like that, the UCD person (or Architect) should probably request to
      talk directly to the customer in order to clarify this particular point.

      But consider a scenario like this. The customer actually WANTS a TOTALLY
      open space house and says so to the intermediary. The intermediary
      conveys that to the Architect. The Architect questions that and asks to
      talk to the customer directly to clarify. They meet, and after much
      discussion, and iterative drawing of alternative floor plan with
      feedback from the customer, the Architect realises that the customer
      actually DOES want an open space house with no walls whatsoever between
      the kitchen, dining room and living room. The Architect finds it butt
      ugly and is convinced that it will be completely disfunctional, but
      that's what the client wants. What's the Architect to do in this case?

      The answer should be clear. He who pays for the work gets the last word.
      ----

      The disconnect comes when somebody who "represents"
      the end user(not to overload customer, as Jeff P
      says), pushes through "requirements" that are really
      not beneficial to the end user or what they would
      want. I imagine in my mind a manager type pushing not thought-through
      requirements, but I know that I am guilty of it as well.

      -- Alain:
      This comes back to what Jeff P was talking about earlier, i.e. there is
      a mismatch in terminology between the Agile world and the UCD world when
      we talk about the customer.

      In the Agile world, by customer we mean the person or organisation that
      comissioned the work. Let's call it the Project Funder to avoid further
      confusion. In the UCD world, it seems to me that many practitionners
      define the customer as the people who will be using the software. Lets
      call those the Product Users.

      The needs of the Project Funder overlap widely with the needs of the
      Product User, but they are not one and the same. In fact, sometimes they
      are in opposition. For example, most Product Funders (MS in particular)
      would love to forever lock Product User into using their line of product
      and not be able to migrate to products of their compw etitors. But
      obviously Product Users feel differently. What do you do in such a case?


      Againk, the answer should be obvious. He who pays for the work gets his
      way.
      ----
    • 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.