Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Paying Contractors
Last Post 11 Jun 2014 04:35 AM by Benjamin Korth. 11 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Justin Todd
New Member
New Member
Posts:48
Justin Todd

--
03 Jun 2014 12:13 AM
    Hi,

    What is the best/fairest (to company and contractor) way to pay a contractor for a development project?

    1. Pay by the hour
    2. Pay per feature
    3. Agree on a price for the project?
    4. ?

    Thanks,
    Justin
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    03 Jun 2014 12:23 AM
    In my opinion it is pay per iteration. The customer (PO) can negotiate what will be done in each iteration with the contractor.
    If the team size is stable, there is only a small difference to pay by the hour: In case of pay by the hour the contractor is motivated to do overtime which can make him less productive and decrease the value cost ratio for the customer.
    Justin Todd
    New Member
    New Member
    Posts:48
    Justin Todd

    --
    03 Jun 2014 12:26 AM
    Ok thanks, and if the contractor does not deliver what was agreed within the iteration?
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    03 Jun 2014 01:17 AM
    In an ideal world, the contractor will value customer collaboration over contract negotiation.
    This means, the most important thing when the sprint goal was not reached is to collaborate on how to improve for the next iteration.
    You could think of a situation where the contractor is only payed if he reaches the sprint goal. In this case he would be motivated to set sprint goals which are not too challenging, and it might even be that the reason for not reaching the goal is missing feedback from the customer.
    You could even think of a basis payment for each sprint (effort) and a bonus for delivered value (if sprint goal was met).
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1614
    Ian Mitchell

    --
    03 Jun 2014 01:45 AM
    It's generally best to fund the current Sprint up front and at the client's risk. This puts the onus on the client to de-risk delivery by collaborating via the PO throughout the Sprint, and to see early demonstrations. This is usually better than allowing a client to turn their noses up at an increment they have not been sufficiently involved in.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:247
    Olivier Ledru

    --
    03 Jun 2014 10:07 PM
    What about dividing the risk, by having the client paying half the price at the beginning of the sprint, and half the price at the sprint review ?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1614
    Ian Mitchell

    --
    03 Jun 2014 11:08 PM
    It's possible, but I'd have reservations about such an arrangement. A sprint should be short enough to be irreducable in terms of mitigating business risk. Or to put it another way, a sprint should be the smallest "chunk" of business risk that can be taken on and paid for.

    If a client can only pay for a fraction of a sprint, I'd question whether the sprints are actually short enough to meet their risk appetite.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    03 Jun 2014 11:49 PM
    I think what Olivier meant was that the client pays some price in advance for the sprint being executed, and another price at the end if the value is delivered. This is what I meant with basis payment and bonus.
    In my opinion this can be a compromise between paying each iteration (regardless if value was delivered or not) and paying only for successful iterations where the committed value was delivered.
    I have made good experience with time and material. If you are payed depending on the reached sprint goal, this might lead to heavy and time wasting discussions at sprint planning about what can be done in the sprint, and even discussions at the review about if the sprint goal was met.
    Justin Todd
    New Member
    New Member
    Posts:48
    Justin Todd

    --
    04 Jun 2014 12:34 AM
    Well, the project is long enough for us to change the way we work. So we can start a certain way and if we find that its not working, we can then try a different route.

    Setup is this.
    DT are the contractors
    UAT/PO/SM are the company
    Client is,well, the client.

    First option will be to pay per sprint as I feel that this will incentivize all parties, contractors, company and client, to perform their tasks/responsibilities at the highest level. DT will ensure quality and efficiency. SM/PO will ensure that that supply the right information and are always available. Same goes with the client, but they will also ensure that they are clear about what they want.

    Might even try one or 2 sprints towards the end using NoEstimates.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:247
    Olivier Ledru

    --
    04 Jun 2014 12:49 AM
    I'm not sure if having the PO and the SM on the same side is better than having the SM with the Dev Team.
    Of course, having the Scrum Team tears in separate company is not the best case, so each option has some drawbacks.
    Justin Todd
    New Member
    New Member
    Posts:48
    Justin Todd

    --
    04 Jun 2014 12:53 AM
    Agreed, but unfortunately in this case there is no other option. Luckily the relationship between contractors and company is very good.
    Benjamin Korth
    New Member
    New Member
    Posts:16
    Benjamin Korth

    --
    11 Jun 2014 04:35 AM
    Scenario A Paying per hour:
    The worst case is that the contractor makes overhour to optimize his cashflow.

    Scenario B Paying per sprint:
    The worst case is that the client asks for getting amount of work done and is less prepared for making compromises on reaching the sprint goal.

    Both scenarios are resulting in overhours, but normaly the client has more pull. So I tend to recommend pay per hour and limit the work time.
    The contractor is then not payed for overtime and has no reason to make it. The client has no (financial) advantage on insisting on the initial sprint Goal instead making compromises.

    In my opinion making compromises and focus on the absolute necessary is the key benefit of working with scrum.

    Kind regards
    You are not authorized to post a reply.


    Feedback