Are Agile Project Deliverables Generally Tied To Stage Payments?

Question

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?

Answer 1

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.

Answer 2

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.