Do software developers operating under some sort of agile development cycle and presenting a series of 'deliverables' to their customer generally expect—or contract—their clients to make a stage payment per acceptable deliverable?

I ask as many systems take months to produce, test, and implement at the client's HQ and the developers have continual outgoings on salaries, rent, sub-contractee payments, etc. It's hard to see a bank holding their nerve for long without cash flow. House builders demand stage payments. Machinery builders demand deposit up front against materials. So why not software developers?


2 Answers 2


Agile Projects Generally Work Best When Billed as Time-and-Materials

Do software developers operating under some sort of agile development cycle and presenting a series of 'deliverables' to their customer expect—or contract—their clients to make a stage payment per acceptable deliverable?

In the world of contracting, anything the parties agree on (provided it isn't illegal) is generally acceptable. So, you could certainly do this. Whether or not it is common is a different question, and that's likely hard to quantify.

Agile projects could be structured around piece-work, or around stages or phases of the project. However, such payment terms are usually a thinly-veiled attempt at fixed-cost pricing for fixed-scope specifications. This doesn't work well with an iterative development methodology that explicitly values collaboration over contract negotiation.

In my professional experience, agile projects are most effective when billed on a time-and-materials basis, with project controls on both sides to manage scope, budget, and risk. In particular, Scrum is designed to establish a cadence for the project such that a potentially-shippable increment is delivered each Sprint. The project can be stopped at the end of any Sprint, either because the goals were met or because the project has successfully "failed early."

If you want the benefits of an agile methodology, then you need to use a contract structure that encourages collaboration and continuous engagement rather than risk management. Contracts that shift all the risk to the vendors, especially the risk of potential process issues originating on the client side, almost always prevent real collaboration on emergent designs.

  • 1
    So you say that stage payments preceded Agile and were thus not a prime motivation for this project development cycle; it was more about loosening up working relations between client and provider, allowing changes on-the-fly when the client desired them or where clients' original specs turned out poorly in reality. All of that assumes maturity and trust between client and provider - which isn't always the case.
    – Trunk
    Nov 26, 2016 at 17:11
  • @Trunk T&M works best because it means you don't have to write and agree a spec, which is presumably what you are trying to get away from with aglie. If the client wants a spec, you can still do aglie. you just dont accept changes to the spec
    – Ewan
    Nov 29, 2016 at 15:55
  • I hear what you are saying about amending the project spec as the project evolves. But as far as I can see, the absence of a spec agreed to by client and provider alike will only lead to conflicts on payments. If an Agile contractor produces a deliverable that the client decides is not really what is best for his company then how eager would that client be to make a stage payment then ? In short, while the software contractor will always be happy to pay on a T & M basis - especially monthly! - the client consciously or subconsciously only feels right paying for definite USABLE product.
    – Trunk
    Nov 30, 2016 at 16:53
  • 2
    @Trunk You keep trying to retcon this to fit your preconceived notions that staged payments are preferable or de rigueur in an agile context, or for contracting in general. They are neither. If you want to be agile, you need to educate your customers on how to actively collaborate rather than trying to shoehorn agile practices into a waterfall process focused on fixed, up-front specifications and scope.
    – Todd A. Jacobs
    Nov 30, 2016 at 17:07
  • @Trunk Please note that comments are not for extended discussion. If you have related questions, it would be best to formulate them as new questions that can optionally be linked back to this one.
    – Todd A. Jacobs
    Nov 30, 2016 at 17:08

Most non-trivial software development work tends to be billed as T&M. The agile approach with a T&M contract is attractive to both the customer and the vendor and generally has important advantages over payment on deliverables:

  1. Reduced risk. If a tested, working product is delivered continuously / incrementally then the amount of the work that is "at risk" at any one time is very small. The customer can walk away with a potentially deployable product and without losing much. This contrasts with up-front specified deliverables where the risk of non-delivery or a poor quality product is bound to be greater and dropping the software vendor can be extremely difficult.

  2. Reduced cost. Vendors tend to add a very significant premium on to fixed-price deliverables. T&M is typically much cheaper.

  3. Improved collaboration. Fixed-deliverable, fixed-price contracts are really only attractive where there is a high degree of trust between vendor and customer. T&M contracts demand collaboration but they also give the opportunity for vendor and customer to demonstrate their commitment to each other - and to walk away if they are not satisfied.

  • But what does T & M mean in cash flow ? Does it mean that each satisfactory deliverable will be paid for on a T & M basis immediately afterwards ? If so, I get the popularity of T & M from the software provider's point of view - and from that of his banker ! If it simply means that so much time and so much "materials" is added to the invoice after each deliverable and the software company living on a credit line till the final deliverable, then I wonder how feasible that is going to be for all too human software company owners and their banker. N projects => N credit line components . . .
    – Trunk
    Aug 28, 2021 at 21:32
  • 3
    @Trunk Time and materials (T&M) means the vendor is paid for the working time they put in - usually at a person/hourly or person/daily rate - not per deliverable. In every such project I have worked on the customer is billed once per month. Cash-flows based on monthly billing cycles is the way most IT service companies charge for their services.
    – nvogel
    Aug 29, 2021 at 8:07
  • Got it. That's the cash flow sorted. Are you around long enough to know if this T & M monthly payments also operated for non-agile projects, e.g. waterfall project cycles ?
    – Trunk
    Aug 29, 2021 at 11:42
  • 1
    @Trunk Most of the software projects I have been involved with that could be described as "waterfall" have been T&M billed monthly. I have also seen gated payments made on key milestones but those seem to be much rarer these days than in the past.
    – nvogel
    Aug 30, 2021 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.