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

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

Expand Messages
  • Rob Keefer
    Yes, I like this differentiation, and in Cooper s Inmates book he goes to great lengths to point out that business folks (funders) know what is viable, but
    Message 1 of 49 , Jul 21, 2005
    • 0 Attachment
      Yes, I like this differentiation, and in Cooper's "Inmates" book he goes to great lengths to point out that business folks (funders) know what is viable, but not necessarily what is useful. He goes on to say that a smart business will understand this, and delegate their decision making authority to a UX designer whose job it is to find out what the user wants.
       
      To me, part of the answer to this whole problem lies in the fuzzy world of human-human interaction.
       
      I have worked with good agile teams where the everyone has the courage to push their agenda when appropriate, and has backed down when appropriate. Meaning, that the UX person pushed her agenda when the decision was UX related, and the developer backed down, but the developer pushed his agenda when the decision was technical, and the UX person backed down.
       
      I have also seen a QA person completely change a feature because when it came time to 'review' what the UX person had planned, her strong personality pushed hard for something she liked, and the UX person, being timid, gave way. The company's "process" called for UX to set the direction and development/QA to review. What actually happened, is UX made a proposal, and then it changed until development/QA approved.
       
      We often like to look at these these problems from a mechanistic perspective because we hope to control a situation using some kind of process/system/technique. However, if a business person or developer have an ego problem, and other team members are "courage deficient" the team/product is going to have problems no matter what system/hierarchy you put in place.
       
      - Rob
       


      "Desilets, Alain" <alain.desilets@...> wrote:
      > One point that I don't think has been raised here, is that a
      > software `product' may not only have one customer.  

      Yes. Part of the problem here is that there is an XP jargon term
      "customer", which is generally not the person who pays for and uses the
      software. In a lot of environments, "product manager" is the correct
      term for what XP calls the "customer".

      -- Alain:
      Again:

      Agile Customer = Project Funder = Group of people who pay for the
      DEVELOPMENT of the software

      UCD Customer = Project User = Group of people who USE (and possibly, but
      not always, BUY the software)

      As developpers, we report to the the Project Funder, and therefore our
      PRIME concern is to satisfy the Project Funder's needs.

      Of course, unless the Project Funder is completely clueless, satisfying
      his needs will mean we have to pay a lot of attention to the needs of
      the Project User. But the Project Funder needs to be in charge, not the
      Project Users.
      ----
    • 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.