The agile methodology reflects how software is built. It’s complex and messy. So what is the best way to pay?

The agile manifesto does not mention when developers should be paid

I have been thinking about David Kellam’s comment about my last agile post:

Agile simply reflects the nature of software development, and specifically the nature of innovative software development.

I agree. The agile methodology simply reflects how software is built. When building something new, agile is a way to manage the complexity of an inherently changeable and fluid process. The focus needs to be “customer collaboration over contract negotiation”¹.

However, the agile manifesto does not mention when developers should be paid.

Let’s just throw cash at it

So what do you do if you have no software development expertise and want to pay a supplier to build software for you? The solution cannot be to throw an indeterminate amount of cash at the supplier until they (hopefully) build the product to your satisfaction.

In other words, agile is not an excuse.

Keep contract pricing incentives as simple as possible. But keep them.

Building a house is also a complex and messy process. As a customer², it is perfectly reasonable to ask a builder to quote a fixed price to build your house. The builder will ask for input as needed and change the price if the customer asks for something new or different. There is risk on the builder’s side, but the builder (not the customer) is the expert and controls and manages the project. The customer pays the builder to manage the risk.

Similarly, if you are a customer with no software development expertise and want to pay a supplier to build software for you, it is perfectly reasonable to ask for a fixed price. However, you will need to accept (like with the house) that your supplier will seek your input but you won’t get to micromanage how the house is built. If you want to change something then the price will go up.

Use agile. Or use waterfall. Or don’t. The customer won’t care as long as the software is delivered on time and on budget.

The customer usually doesn’t care how software is built

The customer doesn’t care how software is built. Just that it’s built well, relatively fast, and for a reasonable price.

The agile (i.e. software development) contracting risk if we don’t include waterfall pricing breakpoints (i.e. a pricing incentive to deliver on time and on budget) is the supplier iterating, at the customer’s cost, without producing much or any great production code. Removing this supplier risk means removing the supplier’s financial incentive to build fast and smart.

If you pay your supplier to build then it is reasonable to ask them to take on pricing risk with some sort of fixed price mechanism. Alternatively, if the project really needs constant agile customer input then the customer needs to carefully track and manage the project. The customer needs to be able to get out, or replace the supplier, if the project goes off the rails.

Sometimes avoiding the problem is the best solution

As a customer³, a better approach might be to just buy an existing product or build an in-house software development team. It is no wonder that many customers decide to just buy an existing completed solution, or build software development teams in-house to avoid this challenge.