Skip to content

How to structure an Agile software development contract

How do you structure a contract for the development of software in a world that has learned valuable lessons from Waterfall? It’s a challenge. From the perspective of a customer, the following guarantees are desired:

  • A fixed set of functionality
  • A fixed cost
  • A fixed date
  • A fixed (high) quality bar

Unfortunately, fixing all of those levers is not realistic, and a primary reason Waterfall software development has failed. What makes us think it can succeed with contract development? In short, the risk is high (e.g., no working software until late in the process) and the probability of success is low.

What are the alternatives? First, some fundamental principles of execution:

  • Transparency, including near-real-time visibility into project progress — vs. post-project legal action
  • Commitment to delivering in small batches, which are easier to understand and deliver — vs. lengthy duration until working software is produced
  • Frequent collaboration to ensure the direction is correct — vs. going dark and delivering months later
  • High quality is non-negotiable — vs. taking shortcuts and building up technical debt

Let’s cover some models for contract-based software development (e.g., outsourcing or augmented development team) along with their suitability to Agile teams, where traditionally time and cost are typically fixed, but functionality flexes.

Variable price, fixed scope

In this model, the customer knows what they want, and are willing to pay a variable fee to get it, understanding that software development is an imperfect craft that cannot be wholly predicted. This model accounts for the necessary time and materials. The risk is the project may balloon out of control and cost much more than initially budgeted.

Agile fit = medium, since a ranked backlog can still drive development

Fixed price, variable scope

A product backlog (functionality) is agreed upon that has work in sequential order. The team works through the backlog until the budget is met, at which point additional cost can be agreed upon for increased functionality. The risk is the initial budget may not produce a workable product (i.e., incomplete).

Agile fit = high since Agile typically flexes with functionality

Fixed price, fixed scope

Here, the date is left is to flex if necessary, but two key levers are adjusted. Development can be iterative, with smaller batches of committed scope. The risk is the software may be delivered much later than needed, and it may take more iterations than expected for a suitable product. Plus, it is risky for the development team and may severely hit margins.

Agile fit = low, since the date is the primary flex point

Start time and materials, fixed price later

A suitable model when there are many unknowns at the start of the project. Frequent collaboration is used to clarify scope with enough research to provide higher confidence estimates. Then, a more predictable cost can be inserted into the contract. The risk is that the scoping phase may use much of the budget. The fixed price portion may have the same dangers as discussed previously, but the risk is lower.

Agile fit = medium, since the planning portion is Agile, but the delivery is more Waterfall (with more certainty)

Capped costs with incentives

The lower-bound cost and upper-bound cost for the work is determined with incentives for delivery, such as date targets or functionality targets. If the team meets all of the targets, the upper bound cost is paid. The risk is that the bound costs may be difficult to determine, and the lower bound cost may not be agreeable to the development team.

Agile fit = medium/high since there is flexibility in how the team works

Combination of models

This is a combined model of time and materials to start (a “sprint 0” to plan and determine longer-term roadmap and backlog) with iterative development (e.g., 10-week increments), commitments for the first 6 weeks of development and stretch incentives at the end of the increment. The risk is that the contract becomes more complex, and a new one is typically needed every increment.

Agile fit = high since planning is Agile, and the incremental model also fits with Agile methodologies

The right model is dependent on several factors, such as how well-known the scope is, the complexity of the software, the overall budget and delivery timeframes. The principles to ensure success with outsourcing are referenced here. A critical condition, however, is an Agile mindset by both the development team and customer. Agile development teams typically have more success with delivering high-quality commitments on time, so an Agile software development contract that does not force Waterfall thinking is generally preferred.

Crosslake often leverages Agile principles and methodologies to best meet customers’ needs. If you need a high-powered development team that produces high quality, delivers in small batches for frequent and early feedback, collaborates effectively, and is fully transparent with progress, please do not hesitate to contact us.