Thanks, Shannon, for having us, and welcome to our discussion on Agile contracts. As an attendee, you're going to hear five or six different perspectives on Agile contracts in a very short time. I'm attending in part to see what others have to say because, compared to traditional contracts, we all find ourselves in a bit of a dilemma.
We now understand that digital transformation affects everyone. I recently visited a shipbuilder, expecting to hear about their Agile IT processes. Instead, they discussed using augmented reality to help workers weld ships—demonstrating how disruption is universal. Every business is now a software business.
Fortunately, we now have solutions. The Lean Agile Enterprise, which combines Agile team-level practices with Lean Thinking at the program and portfolio levels, provides a structured approach to navigating this new landscape.
Challenges in Agile Contracting
As I prepared for this talk, I was focused on government contracts. However, just last week, I completed a roadshow in India, which strongly influenced my perspective. We spoke with captive shops and outsourcing firms, all facing the same challenge: they wanted to be Agile, they understood its power, but they lacked permission or clear guidelines. Even when permission was granted, they were unsure about the specifics: Should there be specs? No specs? Estimates? No estimates? Time and materials? Feature-based contracts?
One particularly concerning model I saw was contracting by story points. You can imagine the complexities that arise from that approach. Another major issue is the risk of contested awards, especially in U.S. federal government contracts, where vendors may challenge decisions based on pricing uncertainty. These factors make it difficult to operate in an Agile manner.
We are transitioning from a legacy contracting model based on the Iron Triangle, which assumes that if you provide requirements, you can estimate cost and schedule. However, in reality, cost estimates are often unreliable. Procurement teams want to know whether a project costs $3 million or $4 million, $30 million or $50 million. This traditional approach has been in place for decades, but it doesn't account for evolving requirements. If the requirements change, what happens to the cost and schedule?
Why the Iron Triangle Fails
The Iron Triangle model is no longer effective, and even the spectrum of Agile contract types doesn't fully resolve the issue. On one end, firm fixed-price contracts immediately put suppliers and customers at odds—suppliers aim to minimize effort, while customers try to maximize value for their money. On the other end, pure time-and-materials contracts are more Agile but create uncertainty about value delivery. Government agencies, for example, may prioritize funding a project rather than delivering actual value.
Neither extreme works well. Instead, we need a Lean approach that optimizes economic value for both parties, enables adaptive responses to requirements, and ensures continuous visibility with objective evidence. Agile’s iterative and incremental model provides a breakthrough: instead of relying on requirements burndown charts, we can measure progress through working systems.
A New Approach: Scaled Agile Managed Investment Contracts
At the portfolio level, we’ve learned that investing in large initiatives follows a curve—initial value delivery is slow, then accelerates, then declines due to diminishing returns. This means that investing less than initially expected can sometimes yield the right economic value. However, traditional contracts don’t accommodate this flexible investment model.
Suppliers also need stability. If contracts are purely time-and-materials, suppliers risk losing assigned teams at any moment, leading to opportunity costs and difficulties in securing long-term engagements. A better model should motivate both parties to build the best possible solution within economic constraints.
One promising approach is the Scaled Agile Managed Investment Contract. This model is designed for large-scale Agile initiatives, typically involving 50 to 500 people. In these scenarios, contract overruns aren't just in the thousands—they can be tens or even hundreds of millions of dollars.
Structuring Agile Contracts Around Teams
Agile teams operate in a well-defined structure. Teams of fewer than ten individuals work in fixed sprint lengths, delivering tested, validated value. This structure provides a foundation for a new Agile contract model.
The core idea is simple: hire teams, not individuals, for a sprint. Instead of specifying deliverables up front, the contract commits to funding a set number of feature teams for a specified period, measured in sprints. The pricing model becomes: X dollars per feature team per sprint.
At a higher level, program increments (PIs) provide additional structure. A PI consists of multiple sprints—typically three to five—allowing for adaptive planning and adjustments. Before committing to PI-1, both parties agree on:
- The vision and roadmap (though not necessarily detailed specifications)
- The number of teams required
- Ramp-up and ramp-down mechanisms
Once agreed, the contract commits to a single PI with a small initial team. The execution phase begins with joint planning, execution, and system demos every two weeks. These system demos, rather than burndown charts, become key contract milestones.
Progress Measurement and Contract Adaptation
The system demo serves as a contractual validation event every two weeks, ensuring transparency and enabling adaptive decision-making. After each PI, stakeholders review progress and decide whether to:
- Add more teams to accelerate development
- Maintain the current pace
- Pivot in a new direction
- Ramp down towards completion or maintenance
This approach allows for smarter investment decisions. Instead of locking in a fixed scope, stakeholders can assess ongoing value delivery and adjust funding accordingly. It also prevents premature shutdowns, as teams can transition from development to maintenance seamlessly.
Applying Agile Contracts in Government and Large Enterprises
In highly regulated environments, such as government projects, this model may involve multiple suppliers. A feasibility phase (PI-1) could include parallel efforts from competing vendors, allowing the government to assess feasibility and trust before making long-term commitments.
As the program progresses, stakeholders focus on objective evidence of value delivery rather than rigid contractual obligations. This ensures that contracts remain aligned with evolving business needs.
Conclusion
Agile contracts require a shift from the traditional Iron Triangle approach to a model that balances flexibility with economic stability. The Scaled Agile Managed Investment Contract offers a structured yet adaptable framework that benefits both suppliers and customers.
For more details, you can explore the Scaled Agile Framework on Lean budgets and Agile contracts, which provides further insights into this approach.
That concludes my talk—15 minutes goes by quickly! We'll now move on to the next speaker for another perspective on Agile contracts.