It's nice to hear Stewart’s words about scope—they fit right in. It would have been a disaster if he had said something different! It was also great to hear Athene’s words align well with what I’m about to say. Apologies if this means my talk isn’t as new and original as you were hoping for, but I’m going to provide a template on how you can structure your context. This comes from my experience working with clients, particularly one in mind, and conversations with several companies that approach this differently.
You may have come across my work before. A few years ago, I wrote a piece called Dear Customer: The Truth About Our IT Projects, which you can download for free from the Agile Connection website. It’s a tongue-in-cheek look at how the IT industry structures contracts, what we actually do, and why suppliers often end up winning while clients do not. This piece is also the prologue to one of my books, Sampan, which I encourage you to buy. If you subscribe to my newsletter, you can get the e-book for free—just a small plug!
Fixed Contracts in the Real World
I want to start with a couple of hypotheses. When discussing Agile contracts, people often say, “That’s all very good, but in the real world, clients want fixed-cost, fixed-time, fixed-feature contracts.” This is essentially the housing model: tell me the house size, how long it will take to build, how many bathrooms it will have, and how much it will cost.
As a result, most suppliers feel they must bid on this basis. They believe that since customers want everything fixed, they must comply. That’s the real world, right? But let me challenge that notion.
Some companies are already looking for something different. There are organizations for which the “fix everything” model seems absurd. Why would you fix the entire scope, timeline, and cost upfront? Consider other professions—do you go to a lawyer and say, “I’m accused of murder. How long will it take to get me off? What witnesses will you call? What will the total cost be? On what day will I go free?”
Legal systems don’t work like this. Even buying a house in the UK isn’t fixed-fee; a few years ago, I hired a lawyer on a fixed-fee basis, and it was such a mess that I had to hire a second lawyer to fix the problems.
The same applies to doctors. You don’t walk in and say, “I have this rash—how long will it take to cure, what’s the total cost, and what will be the exact treatment?” Instead, it’s an ongoing discussion: they try something, evaluate, and iterate.
The Reality of Agile Contracts
Yes, many businesses demand fixed contracts, but that doesn’t mean it’s the only way to work. Here’s an observation: the companies I know that work in an Agile fashion—particularly those bidding on Agile contracts—are thriving. There aren’t many companies doing this, but those that do have more work than they can handle, and they can charge premium rates.
I’d also like to suggest that companies capable of working under an Agile contract—where scope is flexible—are often the better companies. They are confident in their abilities. The companies that insist on fixed contracts are often the ones that lack confidence in their skills and want to lock clients into rigid agreements.
Real-World Example: Zone Digital
Let’s take a real example. I worked with Zone Digital, a digital agency, on a large project for a construction company. Initially, the client wanted a simple “lift and shift” of their existing system. They wanted to start quickly, so they engaged Zone Digital without finalizing contract details.
The team was assembled, and I provided training for both the supplier and the client. They started working iteratively, delivering features, and holding regular demos. Three months later, the construction company awarded Zone Digital a £1 million contract with no predefined scope. The objective was clear, but the specific features and product backlog would be determined collaboratively by the joint team.
Template for Agile Contracts
An Agile contract needs to be paired with an execution model that supports it. If you have an Agile contract but don’t structure the work accordingly, you’ll face challenges. Here’s how to set it up:
1. Shared Risk
Traditional contracts place all risk on one party—usually the supplier. This can lead to padded costs and rigid schedules. Conversely, if the client bears all the risk, suppliers lack incentives to work efficiently. Agile contracts should share risk to ensure both parties remain invested.
2. Defined Objective, Not Defined Scope
Agile contracts focus on an overarching goal rather than a fixed feature set. For example, the contract may state, “Build a CRM system to increase sales”, but the details will emerge through collaboration.
3. Hiring for Services, Not Scope
Instead of a contract that promises delivery of 50 specific backlog items, the agreement should be for development services that help the client discover, build, and adapt solutions as needed.
4. Fixed Time and Cost, Flexible Scope
You can fix the time and cost by defining the capacity—how many people will work on the project. The contract should allow easy exit clauses or operate on a rolling basis.
5. Start Small and Grow
Begin with a small team and a small piece of work. If it goes well, expand gradually. Clients and suppliers should work as a combined team, including business analysts, product managers, and developers from both sides.
6. Maintain High Quality
High quality ensures an easy exit. If quality is low, sunk costs make it difficult to walk away. The team should release early and often—ideally at the end of the first sprint (two weeks) and continuously after that.
7. Regular Governance
Since Agile contracts allow flexibility, governance is crucial. Regular reviews ensure alignment with goals and expected outcomes. If a project isn’t delivering value, adjustments can be made quickly.
Strategic Use of the Iron Triangle
Traditional project management uses the “Iron Triangle” (scope, time, and cost). Agile shifts this by:
- Fixing the goal while allowing scope to evolve.
- Strategically fixing the schedule—determining how long the project should run.
- Fixing the cost by determining the team size and duration.
By controlling time and budget, the project adapts dynamically within constraints.
Minimally Viable Teams
Start with a small, focused team and expand only when necessary. Determine upfront how much it’s worth investing—whether £250,000 or £2 million—and work within those constraints. Let the money follow success.
Conclusion
Agile contracts should emphasize:
- Risk-sharing between client and supplier.
- Clearly defined objectives rather than rigid scope.
- Fixed cost and time while allowing flexible scope.
- Continuous delivery, high quality, and frequent governance.
- Starting small and expanding as needed.
These principles create successful Agile contracts that benefit both parties, ensuring adaptability and delivering real value.
Thank you!