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

Selling Customers on SCRUM (sales agreements)

Expand Messages
  • Robert Martin UncleBob
    ... Don, There are a number of strategies to use here. They range from: - Tell the customer nothing, and use agile methods internally to - Tell the customer
    Message 1 of 8 , Jul 29, 2003
    • 0 Attachment
      > -----Original Message-----
      > From: scrumdevelopment@yahoogroups.com
      > From: dweiss@...
      > Subject: Selling Customers on SCRUM (sales agreements)
      >
      > I have been studying Agile Development processes for a short
      > time now and am
      > particularly interested in Scrum. I am convinced that our
      > company would
      > greatly benefit by shifting to Scrum from a more traditional,
      > waterfall-like
      > process used now. I think I could get management buy-in to
      > try it but for
      > one stumbling block -- as part of my pitch, I need to be able
      > to educate our
      > sales team on how to sell customers on an Agile development
      > approach to
      > software, and how to structure future sales agreements. Most of our
      > customers want stable, fixed bids up front before they will
      > proceed with
      > development, and our partners want to know cost and profit information
      > before they will commit resources. Fixed bids have not been
      > very kind to
      > us, as the customer rarely knows exactly what they want at
      > the onset (which
      > is why I think Scrum would be such a good fit!) Does anyone have any
      > information that would help?
      > Thanks in advance :).
      > - Don Weiss

      Don,

      There are a number of strategies to use here. They range from:
      - Tell the customer nothing, and use agile methods internally
      to
      - Tell the customer everything, and let the customer drive.

      Let's look at each in turn. I warn you that your sales folks aren't going
      to want to upset the status-quo, so you'll need management support for these
      ideas. I can tell you that I have used several of these ideas, and they can
      work quite well.

      1. Tell the customer nothing, and use agile methods internally.

      Agile methods provide a better way to estimate and control a project. Even
      when the customer doesn't know you are using them, they lead to better
      results because your internal estimation and control will be better.

      What do you do now when you bid a project? Do you spend a couple of weeks
      or a month analyzing and estimating it so you can bid it? What if, instead,
      you ran a couple of one week agile iterations, developing part of the
      project. What if you measured how much you were able to get done in that
      period. What if you used *that* to help you estimate the total project.
      You'd probably wind up with a better estimate with which to calculate the
      build. Especially if you used the concept of story points and velocity from
      Extreme Programming.

      2. Tell the customer that you will be making incremental deliveries and
      share the risk.

      I've personally used this strategy, and it works quite well. You tell the
      customer that you are going to deliver working software to him every N
      weeks. You will expect his feedback from those sessions, and will
      incorporate it in the subsequent release. This gives the customer a certain
      amount of control.

      As for price, you negotiate a fixed bid for the project as in (1) above, but
      then you convert that into a low time & materials rate, and a suite of
      milestone payments. This is a share-the-risk approach. The customer gets
      to have a certain amount of control during the process, in return he shares
      the risk. If you get done quicker than expected, then your cash flow if
      greater than expected. If you get done slower than expected, then the
      customer has to pay the low T&M rate longer.

      3. Let the customer drive. Tell him you are going to deliver working
      software to him every thirty days, or every two weeks, or even every week.
      I've used this approach with success too. The customer pays straight time
      and materials, but has complete control over what gets developed and when.

      4. Let the customer drive and pay for points. I've used this one too, and
      it worked pretty well. We break the project up into stories as in Extreme
      Programming. We estimate those stories with story points. We use very
      short iterations (one or two weeks) and let the customer drive them. The
      customer pays a fee based upon story points.

      Say we negotiate $1000/story point. If we get 20 points done in an
      iteration, then we bill the customer for $20,000.

      In each of these story driven cases you need to have acceptance tests,
      written or approved by the customer, otherwise you'll get into quibbling
      over whether the stories were finished or not.

      -----------------------------------------------
      Robert C. Martin |
      President & Founder |
      Object Mentor Inc. | unclebob @ objectmentor dot com
      PO Box 5757 | Tel: (800) 338-6716 x15
      565 Lakeview Pkwy | Fax: (847) 573-1658
      Suite 135 |
      Vernon Hills, IL, | www.objectmentor.com
      60061 |
      -----------------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.