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?

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?


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 '16 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 '16 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 '16 at 16:53
  • 1
    @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 '16 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 '16 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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