10 min read • Guide 831 of 877
Agile Contracting Models
Traditional contracts fight agile. GitScrum helps teams manage agile engagements with visibility and metrics that support flexible contracting models.
Contract Challenges
Why Traditional Fails
TRADITIONAL VS AGILE CONTRACTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FIXED-PRICE, FIXED-SCOPE: │
│ ───────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CONTRACT: Build system X with features A, B, C, D ││
│ │ for $500,000 by December 31 ││
│ │ ││
│ │ PROBLEM 1: Requirements change ││
│ │ Client: "We need E instead of D" ││
│ │ Vendor: "That's out of scope, change order" ││
│ │ Result: Conflict, delays, cost overruns ││
│ │ ││
│ │ PROBLEM 2: Discovery during development ││
│ │ Team: "Feature B is way more complex than estimated" ││
│ │ Options: Cut corners OR blow budget ││
│ │ Result: Quality suffers or cost overruns ││
│ │ ││
│ │ PROBLEM 3: Learning ││
│ │ Team: "Users don't actually want A, they want F" ││
│ │ Contract: "Build A anyway, it's in scope" ││
│ │ Result: Building the wrong thing ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CORE TENSION: │
│ │
│ FIXED-PRICE assumes: AGILE assumes: │
│ • Scope known upfront • Scope will evolve │
│ • Change is a problem • Change is expected │
│ • Plan then execute • Discover while building │
│ │
│ THE CONTRACTS DON'T FIT THE PROCESS │
└─────────────────────────────────────────────────────────────┘
Agile Contract Types
Alternative Models
AGILE-FRIENDLY CONTRACTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODEL 1: TIME & MATERIALS (T&M) │
│ ─────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pay for: Time worked at agreed rates ││
│ │ Scope: Flexible, decided as you go ││
│ │ ││
│ │ ✅ Full flexibility ││
│ │ ✅ Can adapt to learning ││
│ │ ⚠️ No cost predictability ││
│ │ ⚠️ Client bears all risk ││
│ │ ││
│ │ VARIATION: T&M with cap ││
│ │ "T&M up to $500K, renegotiate if approaching" ││
│ │ Adds predictability while keeping flexibility ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODEL 2: FIXED PRICE PER ITERATION │
│ ────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pay for: Sprint/iteration at fixed cost ││
│ │ Scope: Prioritized at start of each sprint ││
│ │ ││
│ │ Example: ││
│ │ "$50K per 2-week sprint, 10 sprints planned" ││
│ │ Client prioritizes backlog each sprint ││
│ │ Can stop after any sprint ││
│ │ ││
│ │ ✅ Predictable cost per sprint ││
│ │ ✅ Flexibility on scope ││
│ │ ✅ Exit points built in ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODEL 3: TARGET COST │
│ ──────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Target: $500K for estimated scope ││
│ │ Range: $450K - $550K acceptable ││
│ │ ││
│ │ If under target: Share savings 50/50 ││
│ │ If over target: Share overrun 50/50 (up to cap) ││
│ │ ││
│ │ ✅ Aligned incentives ││
│ │ ✅ Both parties share risk and reward ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Advanced Models
ADVANCED AGILE CONTRACTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODEL 4: MONEY FOR NOTHING, CHANGE FOR FREE │
│ ─────────────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MONEY FOR NOTHING: ││
│ │ Client can terminate early ││
│ │ Pays 20% of remaining contract value ││
│ │ Vendor gets predictable revenue ││
│ │ Client can stop when "done enough" ││
│ │ ││
│ │ Example: ││
│ │ 10 sprints at $50K = $500K contract ││
│ │ After sprint 6, client has enough value ││
│ │ Remaining: 4 sprints = $200K ││
│ │ Client pays: 20% × $200K = $40K to exit ││
│ │ Total paid: $300K + $40K = $340K ││
│ │ Saved: $160K ││
│ │ ││
│ │ CHANGE FOR FREE: ││
│ │ Client can swap backlog items of equal size ││
│ │ No change orders for equivalent work ││
│ │ Total scope stays same, contents flexible ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODEL 5: OUTCOME-BASED │
│ ────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pay for: Outcomes achieved, not work done ││
│ │ ││
│ │ Example: ││
│ │ "Pay $100K if conversion rate improves 20%" ││
│ │ "Pay $X per user acquired through new feature" ││
│ │ ││
│ │ ✅ Aligned on value, not effort ││
│ │ ⚠️ Hard to define for complex outcomes ││
│ │ ⚠️ Attribution challenges ││
│ │ ││
│ │ Best for: Clear, measurable business outcomes ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Building Trust
Transparency Mechanisms
TRUST THROUGH TRANSPARENCY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGULAR VISIBILITY: │
│ ─────────────────── │
│ │
│ SPRINT DEMOS: │
│ Every 2 weeks, show working software │
│ Client sees progress, not promises │
│ Problems surface early │
│ │
│ SHARED METRICS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CLIENT DASHBOARD ││
│ │ ││
│ │ SPRINT 6 STATUS: ││
│ │ Velocity: 32 pts (avg: 30) ││
│ │ Completed: 6/8 stories ││
│ │ Budget used: 58% ││
│ │ Backlog remaining: 89 pts ││
│ │ Estimated sprints: 3 more ││
│ │ ││
│ │ BURNUP: ││
│ │ ^ ││
│ │ 120│─────────────────────────────● (scope) ││
│ │ 90│ ●───●──── ││
│ │ 60│ ●───●──── ││
│ │ 30│●───●──── ││
│ │ └─────────────────────────► Sprint ││
│ │ 1 2 3 4 5 6 ││
│ │ ││
│ │ Client sees real-time progress ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COLLABORATIVE PLANNING: │
│ ──────────────────────── │
│ Client participates in sprint planning │
│ Client owns prioritization │
│ No surprises about what's being built │
│ │
│ EARLY WARNING: │
│ ──────────────── │
│ Problems raised immediately, not at deadline │
│ Re-plan together when issues arise │
│ No "everything's fine" until it's not │
└─────────────────────────────────────────────────────────────┘
Risk Sharing
Fair Risk Distribution
BALANCING RISK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRADITIONAL (Unfair): │
│ ───────────────────── │
│ │
│ Fixed-Price: │
│ • Vendor bears ALL estimation risk │
│ • Vendor pads estimates defensively │
│ • Client pays for padding │
│ │
│ Pure T&M: │
│ • Client bears ALL efficiency risk │
│ • No incentive for vendor efficiency │
│ • Client worries about billing │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AGILE (Balanced): │
│ ───────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RISK SHARING MECHANISMS: ││
│ │ ││
│ │ 1. TARGET COST WITH SHARING: ││
│ │ Under target → Both benefit ││
│ │ Over target → Both share cost ││
│ │ ││
│ │ 2. EARLY TERMINATION: ││
│ │ Client can exit with small penalty ││
│ │ Vendor gets some protection ││
│ │ Both protected from bad fit ││
│ │ ││
│ │ 3. SCOPE FLEXIBILITY: ││
│ │ Client can change priorities ││
│ │ Vendor doesn't have to absorb extra work ││
│ │ Changes negotiated, not fought ││
│ │ ││
│ │ 4. PERFORMANCE BONUSES: ││
│ │ Vendor rewarded for exceeding targets ││
│ │ Client gets better value ││
│ │ Win-win alignment ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ KEY PRINCIPLE: │
│ Neither party should win when the project fails │
│ Both parties should win when project succeeds │
└─────────────────────────────────────────────────────────────┘
Contract Elements
Key Clauses
AGILE CONTRACT ELEMENTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SCOPE CLAUSE: │
│ ───────────── │
│ ❌ "Vendor will deliver features A, B, C, D as specified" │
│ │
│ ✅ "Vendor will deliver value from the product backlog │
│ as prioritized by Client each sprint. Backlog │
│ contents may change; total effort remains similar." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CHANGE CLAUSE: │
│ ────────────── │
│ ❌ "All changes require formal change order and approval" │
│ │
│ ✅ "Client may substitute backlog items of similar size. │
│ Items varying by >20% require estimation discussion." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TERMINATION CLAUSE: │
│ ──────────────────── │
│ ❌ "Early termination incurs 50% remaining contract value"│
│ │
│ ✅ "Either party may terminate after any sprint with 2 │
│ weeks notice. Termination fee: 20% of remaining │
│ planned sprints." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ACCEPTANCE CLAUSE: │
│ ────────────────── │
│ ❌ "Final acceptance upon delivery of all requirements" │
│ │
│ ✅ "Working software demonstrated and accepted each │
│ sprint. Sprint acceptance = incremental delivery." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COLLABORATION CLAUSE: │
│ ───────────────────── │
│ ✅ "Client will provide Product Owner with authority to │
│ make scope decisions. PO will be available minimum │
│ 4 hours per week for team collaboration." │
└─────────────────────────────────────────────────────────────┘
Success Factors
Making It Work
AGILE CONTRACT SUCCESS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CLIENT REQUIREMENTS: │
│ ──────────────────── │
│ ☐ Empowered Product Owner │
│ ☐ Available for regular involvement │
│ ☐ Willing to prioritize, not just add │
│ ☐ Trust in transparent process │
│ │
│ VENDOR REQUIREMENTS: │
│ ──────────────────── │
│ ☐ Genuine agile capability │
│ ☐ Radical transparency │
│ ☐ Collaborative mindset │
│ ☐ Willingness to surface problems │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CONTRACT STRUCTURE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RECOMMENDED APPROACH: ││
│ │ ││
│ │ 1. START SMALL ││
│ │ • 2-3 sprint pilot ││
│ │ • Build trust, validate fit ││
│ │ • Low commitment for both ││
│ │ ││
│ │ 2. EXTEND IF WORKING ││
│ │ • Longer engagement ││
│ │ • Better terms as trust builds ││
│ │ ││
│ │ 3. REVIEW REGULARLY ││
│ │ • Quarterly contract review ││
│ │ • Adjust terms based on relationship ││
│ │ ││
│ │ AVOID: ││
│ │ Long fixed-scope contracts before trust established ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RELATIONSHIP > CONTRACT: │
│ Best contract can't save bad relationship │
│ Good relationship can survive imperfect contract │
└─────────────────────────────────────────────────────────────┘