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

Selling XP to my customer

Expand Messages
  • Nigel Thorne
    Hi, Ok I m new to XP, and I am trying to sell the idea to my boss. The problem is this.. he wants to pay for completed functionality, and I want to be paid for
    Message 1 of 4 , Dec 7, 2000
    • 0 Attachment
      Hi,

      Ok I'm new to XP, and I am trying to sell the idea to my boss. The
      problem is this.. he wants to pay for completed functionality, and I
      want to be paid for the time I put in.

      Here is what I have thought about..

      To prevent arguments about.. "well why aren't you doing 5 Ideal
      Engeneering days a week each?", I am shying away from the term "ideal
      engineering day". The aim of them is to allow the customer to
      schedule his stories, cos he knows the relative sizes of the stories
      and the speed that development is progressing.

      From my point of view "ideal engineering days" are a measure of how
      difficult the problem is. I want to be able to estimate the size of
      the problem, and adjust how long I think they are going to take,
      as "yesterdays weather" allows... By estimating the "size of the
      problem", not the "ideal time needed", I can then justify more easly
      that the project having a velocity.. X problem units per week.

      The customer can then at any point look at how many problem units are
      outstanding, and the current velocity and judge the time it will
      take.

      As for being paid for functionality..

      I can now have a set charge for an itteration. Customer looks at the
      velocity, and schedules stories for the itteration. If the velocity
      is too low, he can call an end to development or renegociate the cost
      per itteration.

      If the estimates are understimated, then I will drop stories from the
      itteration as per ususal, but only get paid for the persentage of the
      stories that I signed up for that itteration that got completed.

      The nice bit about this is that because of "yesterdays weather" the
      next itteration I would only have to sign up for less problem units
      to get the full itterations pay.

      Alternatively, if I overestimated how hard a story was, then I would
      finish early, and so be able to take on more stories, and so earn
      more for the itteration than usual.. ie I do 110% of an itteration,
      so I get more money..

      Due to "yesterdays weather", this feeds back, and I would then have
      to do the same ammount in the next itteration to keep getting a full
      itterations money.

      As a result, you end up doing a steady ammount of work for a steady
      ammount of pay, and the customer feels he is paying for
      functionality.

      One hole I see, is that if the developer finished an itteration
      early, and doesn't request more stories, then he will get paid a full
      itterations money for part of an itterations work.. and still be able
      to do the same next itteration. This is fine, as long as the customer
      is happy with the ammount of money being paid, and the rate of
      progress.. if not, then is it up to the customer to say she is paying
      too much?

      Can anyone think of some graphs that would allow you to keep an eye
      on this?

      Any ideas about this? Any problems you can forsee?

      Cheers
      Nigel Thorne
      Lead AI programmer
      i!Play Limited
    • Russell Gold
      ... Essentially, he is looking for a fixed-price arrangement. Take a look at for
      Message 2 of 4 , Dec 7, 2000
      • 0 Attachment
        At 02:55 PM 12/7/2000 +0000, Nigel Thorne wrote:
        >Ok I'm new to XP, and I am trying to sell the idea to my boss. The
        >problem is this.. he wants to pay for completed functionality, and I
        >want to be paid for the time I put in.

        Essentially, he is looking for a fixed-price arrangement. Take a look at
        <http://www.egroups.com/files/extremeprogramming/Optional+scope+contracts.pdf>
        for some arguments against this approach.

        >One hole I see, is that if the developer finished an itteration
        >early, and doesn't request more stories, then he will get paid a full
        >itterations money for part of an itterations work.. and still be able
        >to do the same next itteration. This is fine, as long as the customer
        >is happy with the ammount of money being paid, and the rate of
        >progress.. if not, then is it up to the customer to say she is paying
        >too much?
        >
        >Can anyone think of some graphs that would allow you to keep an eye
        >on this?

        How about an earned-value graph? I have an explanation of these at
        <http://www.netaxs.com/~russgold/evdemo/index.html>
        These have the advantage of allowing you to see project status over time.
        When the earned value graph flattens out, it is a very obvious sign that no
        progress is being made.
      • Kevin Smith
        In a trusting relationship, this sounds like a nice compromise. There is room for abuse, as you noted, if the development team does not sign up for extra
        Message 3 of 4 , Dec 7, 2000
        • 0 Attachment
          In a trusting relationship, this sounds like a nice
          compromise. There is room for abuse, as you noted, if the
          development team does not sign up for extra tasks.

          Similarly, if velocity goes down for one iteration, the team
          would have to be honest enough to "try" to get it back up
          the next time, rather than settling in at a lower velocity
          just because it's easier.

          The customer would have to understand that velocity may
          change over time, because it really is measuring actual work
          against estimated work. If estimating styles change (perhaps
          people are becoming more accurate), then velocity will
          change, even if total output remains the same.

          Kevin

          On Thu, 07 Dec 2000 14:55:33 +0000 Nigel Thorne <Nigel Thorne <gleep@...>> wrote:

          > Hi,
          >
          > Ok I'm new to XP, and I am trying to sell the idea to my boss. The
          > problem is this.. he wants to pay for completed functionality, and I
          > want to be paid for the time I put in.
          >
          > Here is what I have thought about..
          >
          > To prevent arguments about.. "well why aren't you doing 5 Ideal
          > Engeneering days a week each?", I am shying away from the term "ideal
          > engineering day". The aim of them is to allow the customer to
          > schedule his stories, cos he knows the relative sizes of the stories
          > and the speed that development is progressing.
          >
          > From my point of view "ideal engineering days" are a measure of how
          > difficult the problem is. I want to be able to estimate the size of
          > the problem, and adjust how long I think they are going to take,
          > as "yesterdays weather" allows... By estimating the "size of the
          > problem", not the "ideal time needed", I can then justify more easly
          > that the project having a velocity.. X problem units per week.
          >
          > The customer can then at any point look at how many problem units are
          > outstanding, and the current velocity and judge the time it will
          > take.
          >
          > As for being paid for functionality..
          >
          > I can now have a set charge for an itteration. Customer looks at the
          > velocity, and schedules stories for the itteration. If the velocity
          > is too low, he can call an end to development or renegociate the cost
          > per itteration.
          >
          > If the estimates are understimated, then I will drop stories from the
          > itteration as per ususal, but only get paid for the persentage of the
          > stories that I signed up for that itteration that got completed.
          >
          > The nice bit about this is that because of "yesterdays weather" the
          > next itteration I would only have to sign up for less problem units
          > to get the full itterations pay.
          >
          > Alternatively, if I overestimated how hard a story was, then I would
          > finish early, and so be able to take on more stories, and so earn
          > more for the itteration than usual.. ie I do 110% of an itteration,
          > so I get more money..
          >
          > Due to "yesterdays weather", this feeds back, and I would then have
          > to do the same ammount in the next itteration to keep getting a full
          > itterations money.
          >
          > As a result, you end up doing a steady ammount of work for a steady
          > ammount of pay, and the customer feels he is paying for
          > functionality.
          >
          > One hole I see, is that if the developer finished an itteration
          > early, and doesn't request more stories, then he will get paid a full
          > itterations money for part of an itterations work.. and still be able
          > to do the same next itteration. This is fine, as long as the customer
          > is happy with the ammount of money being paid, and the rate of
          > progress.. if not, then is it up to the customer to say she is paying
          > too much?
          >
          > Can anyone think of some graphs that would allow you to keep an eye
          > on this?
          >
          > Any ideas about this? Any problems you can forsee?
          >
          > Cheers
          > Nigel Thorne
          > Lead AI programmer
          > i!Play Limited
          >
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          > Ad-free courtesy of objectmentor.com
          >
          >
          >
        • Ian Hobson
          In article , Nigel Thorne writes ... Question - are you an employee or a supplier? An employee gets paid whatever
          Message 4 of 4 , Dec 11, 2000
          • 0 Attachment
            In article <90o8d5+pki4@...>, Nigel Thorne <gleep@...>
            writes
            >Hi,
            >
            >Ok I'm new to XP, and I am trying to sell the idea to my boss. The
            >problem is this.. he wants to pay for completed functionality, and I
            >want to be paid for the time I put in.
            >
            Question - are you an employee or a supplier? An employee gets paid
            whatever happens. A supplier charges for business value created for the
            customer (and works out how to do that at a profit - or not).

            On the assumption you are a supplier.....

            Put a price and a confidence on each task. Confidence is "Quote",
            "Estimate", or "Guess". Client also puts an importance - "Necessary",
            "Important" or "Nice to have" - on each story. You try hard to quote as
            much as possible, and at least estimate everything that is Necessary or
            important. This is your preparation for the planning game.

            Try to go with enough important stories quoted to fill the next release,
            plus some over.

            When doing the planning game, your client can spend X over a week - same
            as you achieved last week, but he can only select from the "quote"
            stories.

            If he wants any "Estimate" ones, you must first agree how to remove the
            risk so you can "quote" the price. This might be a split, doing
            investigation work (as a quoted story) or whatever. Maybe some
            clarification will mean you can raise the price from an estimate to a
            quote.

            He will also name the extra you will try for if you have time.

            Now - he buys a fixed price amount of work each week. You can invoice
            every iteration (note spelling) for work completed, tested, delivered
            and working. If you are competent you will earn plenty and have few
            nasty surprises. Treat the extra you get on the good weeks as the price
            for sweating your mistakes right on the (infrequent) bad. If your not
            able to estimate reasonably, (or do the job) you will be found out very
            quickly.

            I know it will be hard, but do measure your time taken, so you can
            convert your idea of an ideal day into actual hours you will take. The
            more accurate (or rather consistent) your estimating the better.

            How are you going to pair program on your own?

            Good luck

            Ian
            Ian Hobson

            Every time we teach a child something, we prevent him from inventing
            it himself. - Jean Piaget
          Your message has been successfully submitted and would be delivered to recipients shortly.