Agile Contracts: How Changing the Way You Work with Vendors Can Streamline Your Development

Agile is disciplined, not reckless.

If you’ve ever worked for an organization that has hired an external vendor, you’ve probably encountered the pattern: projects delivered over budget, behind schedule, and sometimes irrelevant by the time they’re done because market conditions shifted during development. These challenges are especially common for agile organizations working with vendors who run waterfall projects and teams.

Despite the friction, most companies feel compelled to hire those vendors anyway because the vendor has better expertise in a specific technology, process, or application. The goal is for the vendor to build the right things. The problem is in how that relationship is structured.

Those of you who’ve survived a SAFe transformation may already recognize that vendor selection meets all three characteristics of a centralized decision: it’s infrequent, long-lasting, and expensive. You don’t hire vendors often, and when you do, it’s for large initiatives that take significant time and money.

But even with a centralized selection process, your vendor management processes shouldn’t be treated as fixed commitments. Let your vendor manage the delivery details while you maintain your product vision and ensure development continues to address your actual business needs.

The Problem with Fixed-Price Contracts

If your organization operates in an agile fashion, why would you structure vendor engagements around a process that is the opposite? Fixed-price contracts with clearly defined deliverables and six-month timelines don’t support agile development. You can break the scope into epics, features, and user stories, but at the end of the day you’re still operating against a fixed date. You won’t be able to respond to instability in the development process, and you lose the ability to pivot when scope, priorities, or even the vendor themselves need to change.

The Time and Materials Alternative

A Time and Materials contract is used when a vendor is paid on the basis of actual labor, cost of materials, and overhead. Applied to technology vendors, T&M opens up three approaches:

Pay by the hour. The most direct model. You’re paying for actual effort, which removes the incentive to pad scope estimates.

Pay by the story point. You pay for accepted work, priced at a per-point rate. This aligns payment with delivery and gives you a consistent mechanism for measuring progress.

Pay by the sprint. You fund development in sprint-sized increments. This creates natural checkpoints where both parties evaluate progress before committing to the next cycle.

Each of these approaches produces immediate gains:

More control over your design. You can change your requirements at any time because the contract doesn’t lock you out. As long as the cost is justifiable, you have the flexibility to adjust.

More control over project cost. When you don’t commit to a price upfront, you can pivot or streamline as needed. You can also direct investment toward your highest-performing contributors rather than spreading it across teams delivering lower-value work.

Iterative development. The flexibility of having your vendor deliver functioning software that can be measured against every sprint is invaluable. Working software is an objective measure of progress, and your vendor has the opportunity to prove their value every two weeks. If they’re not measuring up, you have the flexibility to find someone who does.

Small commitments. When you sign for X hours, points, or sprints rather than a fixed scope, you have natural decision points at which you can pivot. If your commitments are small enough, you may not need to go through a formal RFP process for every engagement. That flexibility allows you to respond to changing market conditions without waiting on your own legal or purchasing cycles.

One important note: for any of these approaches to work, you need a highly collaborative relationship between the hiring organization and the vendor. Any metric can be inflated in isolation, “my team does 30 stories a sprint and they’re all 20 points.” As long as both parties are present and engaged in the agile process, and no decisions are being made in a silo, you’re protected from artificial inflation.

The Additional Benefit of Point- and Sprint-Based Contracts

If you structure payment by story point or by sprint, you gain one more significant lever: control over quality. In agile, you only get credit when work has been accepted by the Product Owner. That means you only pay for work that meets the quality standard you set. Work that isn’t accepted doesn’t get counted, and doesn’t get paid. This creates a natural incentive for quality that fixed-price contracts don’t have.

How to Write an Agile Contract

Your primary goal is to structure the contract so that payment is based on the amount of work actually delivered. But the point of an agile contract is not to list requirements and specific deliverables. It’s to define the working relationship between the client and the vendor.

Think of it like a team working agreement. You want to define not just the relationship, but also the adequate protections and risk management strategies for both parties. That means:

• Clearly defining how you will work together
• Agreeing on the metrics and measures you’ll use to assess project health
• Tying your monetary relationship to objective, measurable progress

When both you and your vendor understand how you’ll work together and how payment connects to real delivery, you are in a strong position to deliver on time, under budget, and with minimal disruption.

The goal isn’t to establish one party as victorious over the other. It’s to build a relationship where both parties are invested in the same outcome: delivering the right thing, continuously, in a way that serves the business.