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

Re: test-driven iterative user centered design

Expand Messages
  • kauerrolemodel
    ... I don t find that there is a lack of trust based on what you have said. I ve got three kinds of clients... a) Those I ve done work for before. For those
    Message 1 of 9 , Jan 25, 2006
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, "Desilets, Alain"
      <alain.desilets@n...> wrote:
      >
      >> Actually, that's roughly the approach we use and it is the best I've
      >> ever used for all involved. "Fixed price, variable scope". That gives
      >> everyone who wants to know the budget a number and we virtually always
      >> deliver on budget. That makes people happy and life easier for all
      >> involved.
      >
      > -- Alain:
      > Do you find there are problems of trust at sales time or during the
      > project? In other words, do you find your clients are afraid that you
      > will slack off (since payment is not tied to delivery of a final
      > product)?
      >
      > The one time I negociated a fixed price, variable scope contract, I
      > found I could easily address that fear by explaining the transparency of
      > XP to the client, i.e. things like:
      >
      > - single bull-pen area for the whole project team
      > - possibility for the client to have a representative in that bull-pen
      > area at all time (actually, this is not only possible, but highly
      > recommended)
      > - weekly or semi-weekly delivery of working prototypes

      I don't find that there is a lack of trust based on what you have
      said. I've got three kinds of clients...

      a) Those I've done work for before. For those people, it is all about
      what they have the budget to do. They seem to believe we will deliver
      (based on past experience) and that the process will keep us on track
      for at least some of the reasons you mentioned.

      b) Those I haven't done work for before and who found me because they
      were looking for someone to outsource to who would do agile
      development or, more specifically XP. For these people, the big issue
      is both budget and the idea of trying to figure out what they'll have
      at the end of the budget... "Let's see, if I can get a budget for 6
      iterations and we get something that roughly delivers the stories
      we've got laid out, will I get in trouble for not having more stories
      done for that budget or will I have trouble getting the next chunk of
      budget we'll need to get the next stories people will want."

      c) Those I haven't done work for before and who don't know anything
      about XP or agile. These people are all over the map. They almost
      never expect XP or the implications of it. So, we spend a lot of time
      trying to convince them that this is either a good or the best way of
      approaching there project and, if they buy the general idea, trying to
      help them figure out how to get the people they need on the business
      side to devote the time they'll need (and of course, the budget). Of
      course, we are also competing against whatever other alternatives they
      think they have (which runs the gamut from big players, small local
      players, internal players, buy vs. build, etc.). One of their
      objections MAY be what you mentioned, but I've found that people with
      that objection usually have a lot of other issues with respect to
      preparedness or accepting reality that are much bigger issues and this
      objection is usually just a symptom of a bigger underlying problem.
      I'd rather find the bigger underlying problem earlier rather than
      later. Sometimes we can help them work through it, other times they
      go away. Either way, it's OK.

      Ken
    Your message has been successfully submitted and would be delivered to recipients shortly.