The Solution

We need a Tender and RFP process that allows great ideas from multiple vendors to be additive and build on each other instead of creating exclusion/hostility, while maintaining competition, with inflight value delivery metrics akin to an SLA, bound in a contract that takes the risk reduction protections for the buyer from a Firm Fixed Price, with the infinite flexibility for the vendor of the Cost Plus, while incentivizing all parties mutually.

Contract Header

The top of the contract holds the standard non-negotiable information, such as the proper legal names of the entities involved, the mechanisms and net 30/60/90 for accounts payable and receivable both ways, the arbitration clauses (I strongly suggest have your legal team(s) add arbitration in your native country (countries) to avoid court where everyone will lose), the mechanisms/definitions/notifications of default or nonpayment by any party, etc. This will be the sole responsibility of your legal team, they will have standard corporate boilerplate templates for this.

Schedule A.1 – Agile Variables

  • Sprint Cost (SC): How much will each Sprint cost?
    • A team of 10 experts billing at $250/hr per 8hr day will cost you $200K each 2-week Sprint (10 business days).
    • A team of 3 junior staff members outside the US can cost significantly less, but may take longer, depending.
  • Sprint Length (SL): How long will the Sprints be, for that cost?
    • This should be between 1 day and 4 weeks, 2 weeks is industry standard.
  • Sprints Paid for Upfront (SPU): 0-100% of the backlog. But-how many Sprints are you willing to pay an incompetent team upfront to find out they’re incompetent?
  • Minimum Velocity for Sprint Payment (MV): 0-80%. If the team averages 10 Points per Sprint, when they hit 8 Points, have they offset their cost to the customer? Understand- unlike Waterfall, in these situations time or money spent does not equal earned value.
    • The recommendation from experience is to set this no higher than 80%. Any higher and the vendor may inflate estimates to allow buffers (introducing room for failure modes), or may simply walk away if the chance of them getting paid is not high enough to keep them on your job.
  • Renewal Period: How many Sprints is Schedule A good for, before requiring another Schedule A? This gives the customer protections if the Vendor Scrum Master refuses to acknowledge performance issues on the team. A new Schedule A can be agreed to at any time though.
  • IF materials must be procured, you may add the request and approval process here in detail, with the specific email distribution groups (no individual names) to be notified, and the escalation path/process. This shouldn’t differ from any other procurement contract for goods/materials, keep your procurement folks happy, no need to deviate here. Your Product Owner will still need to plan around lead times on Schedules C and D. Some legal teams may require the procurement process to be in the non-negotiable terms in the header, specifically the approval requirements. Allowing the PO/SM to agree to change the procurement process with a superseding Schedule A could be very wise or very unwise, depending on what outcomes you’re looking for.

Schedule B.1 – Base Terms, Events, & Accountabilities

  • Base Terms/Definitions for all capitalized terms (i.e. Sprint, Epic Backlog, Scrum Master, Sprint Planning, Daily Scrum)
  • It is highly advisable to define the purpose and attendees of the Events on this Schedule, but define when they will happen on Schedule C.
  • Who can sign and authorize which new Schedules? Recommended at minimum:
    • Schedule A, C, D, E: Product Owner, Customer Scrum Master, Vendor Scrum Master
    • Schedule B: Legal department reps for both parties, with Product Owner, Customer Scrum Master, Vendor Scrum Master
  • See the Glossary for a list of suggested terms, Events, & Accountabilities

Schedule C.1 – Current Sprint’s Backlog Items, Difficulty Estimates, Event Times

  • The list of what problems the vendor will solve this Sprint, and the vendor’s single integer estimate of how difficult, uncertain, or complex the problem will be to deliver as done. These are the Backlog Items that were planned. Bugs, incidents, and/or super high priority requests that must be done now, that the vendor was given after Sprint Planning, will not be listed here. There’s a failure mode here, see the examples.
  • Signatories will be defined in Schedule B, but it is recommended at minimum the Product Owner and Vendor Scrum Master.
  • Also include the contact info for the vendor Scrum Master, Customer Scrum Master, Product Owner
  • While the purpose of each Event is defined in Schedule B, the Event times for the current Sprint should be defined here. For instance:
    • Sprint Planning was held at 1530 CST on DDMMMYYYY
    • Daily Scrums will be held at 9AM CST via Teams Video Conferencing
    • Backlog Refinement will be held at 1100 CST on DDMMMYYYY via Teams Video Conferencing
    • The Sprint Review will be held at 1100 CST on DDMMMYYYY via Teams Video Conferencing
    • The Retrospective will be held at 1100 CST on DDMMMYYYY in the Demings Room of the 123 Building in New York and Teams Video Conferencing, all NY office staff are asked to attend in person.

Schedule D.1 – Definition of Done

  • What all value delivery must conform to in order to be eligible as complete. May include rules such as translation into one or more languages, internal peer code reviews (make sure this process is well-documented)/defect tooling/SOX compliance screening, etc. BE SPECIFIC!!!
  • Note that delivery as specified by the Definition of Done does not necessarily guarantee anything. We must avoid the traditional waterfall contract leverage that says, “I delivered exactly what you signed for in the technical/functional specifications 2 years ago, it’s not my problem you specified it wrong for what you need today.” The goal is collaboration, frequently, with faster delivery of smaller value.

Schedule E.1 – Epics Backlog

  • The list of prioritized Epics that the customer needs solutions delivered for. Almost all Backlog Items will hierarchically trace lineage to a parent Backlog Item. Most, but not all.

The main idea here is that the Schedules can be superseded simply with signatures from both parties (recommend the customer PO and the vendor SM). Schedules C, D, and E will likely be replaced every Sprint for the first few Sprints, and then E & D will stabilize, with C to be replaced/iterated every Sprint. When the team needs to add/remove talent, add or reduce cost, etc., a new Schedule A can be signed by an authorized Product Owner within the customer, and the Vendor Scrum Master. This scales infinitely, but there must be a set of schedules A, C, D, & E for each team of 10 or fewer people. Get creative, use the Schedule numbers to map to billing codes. Something like, “Schedule C.90026354.32” could be the 32nd Sprint Backlog for the team billing against SAP WBS 90026354. Clear nomenclature will keep the legal and finance folks happy.

Story Points are difficulty estimates, not time estimates. It is important to directly distinguish that Difficulty Estimates (often referred to as “Story Points”) cannot be an equivalent to staff days, or staff hours, they cannot be allotted to an individual on the team, they are for & by the whole team. They absolutely cannot/must not be equivalent to duration estimates. The team doing the work estimates how difficult, uncertain, or complex the backlog Item will be to complete in a Sprint, this cannot be estimated by the customer.

Definition of Velocity. A team that works together often knows roughly how hard different problems will be for that team to complete in a Sprint. The average of those difficulty estimates (Story Points), over 3-5 Sprints is what is known as Velocity. Asking the team how long something will take will result in wild variance. Asking the team if a solution can be achieved in a Sprint (breaking problems/solutions down if not), and then asking how hard the solution will be to deliver as Done, has proven exceptionally accurate.

Examples of Agile Variables

These are given as examples of how different teams with different costs, solving different kinds of problems, could be structured. Offered conversationally, not as doctrine or even a suggestion of how to structure your own variables. It is important to think about why different Sprint lengths (inspection periods) and costs would be advantageous, or shift risk, in your own scenario.

  1. A large expensive team with a base Velocity of 15pts/Sprint, on a longer, low-risk (app migration, etc.) backlog they estimated at 90pts:
    • Sprint Cost: $320K/Sprint
    • Sprint Length: 4 weeks
    • Sprints Paid Upfront: 2 Sprints
    • MV: 12 (actual velocity is 15, 80% of 15 is 12)
    • Renewal Period: 3 Sprints
    • Customer risk mitigated by SPU, MV, Renewal Period
    • Vendor risk mitigated by SC, SL
  2. A small inexpensive team on a rapid prototype, base Velocity of 10pts, backlog of 30pts:
    • SC: $4K
    • SL: 1 Week
    • SPU: 5
    • MV: 4
    • Renewal Period: 20 Sprints. [The current backlog will be gone, but you’ll add new Epics (Signing E.2) next week.]
    • Customer risk mitigated by SC, SL, MV
    • Vendor risk mitigated by SPU, MV, Renewal Period
  3. A large inexpensive team working on multiple small things, base Velocity of 14, backlog of 250pts:
    • SC: $24K
    • SL: 2 Weeks
    • SPU: 2
    • MV: 10
    • Renewal Period: 26 Sprints
    • Customer risk mitigated by SC, SL, SPU, MV
    • Vendor risk mitigated by SL, MV

Typical Execution Examples

Normal Execution Challenges: a team with an Minimum Velocity of 12pts takes on 17pts this Sprint, on Schedule C.16. Any combination of 12pts on that Sprint backlog must result in enough value delivered to offset the cost of the team. This is directly the Product Owner’s responsibility to calculate and understand. The team scores 14 points, the unfinished/rejected work goes back to the top of the backlog, if the PO still needs it. The team earned payment for the Sprint.

Shy Sprint: the same team takes on another 17pts next Sprint, on Schedule C.17. They only achieve 11, for whatever reason, 1 point shy of the MV. The PO has options:

  1. The savvy PO knows that the value delivered, though more difficult than predicted, offsets the cost of the Sprint, and the vendor team has historically delivered value above and beyond expectations, so the PO is happy to pay for the Sprint. This case may need to be added to the non-negotiables, that the PO can authorize payment on a shy Sprint.
  2. The unhappy PO is tired of hearing all the excuses, and withholds payment. If this is a common occurrence, the savvy Vendor Scrum Master will change the dynamic and staffing of the team, and work to negotiate a new Schedule A (and likely an SPU of 0).

Major Scope Changes: the same team is halfway through C.18, when a global pandemic renders the entire Epic backlog (Schedule E) obsolete. The customer creates a new Schedule E, goes into refinement with the vendor, almost certainly signs a new Schedule A, the vendor continues work. In many traditional contracts, the COVID-19 pandemic triggered force majeure escape clauses. While you should still consider a force majeure clause in the header of your Agile Contracts, you will also find you aren’t relying on them so heavily, as with this example.

Abnormal Scrum Accountabilities

  • Vendor Scrum Master – there must be a Vendor-Supplied Scrum Master for the delivery team who can help remove impediments and bottlenecks, who is able to do objectively perform vendor-side delivery performance analysis.
  • Customer-Supplied Scrum Master/Scrum of Scrums Master/Release Train Engineer – there must be a customer-side impediment remover/escalation point for the Vendor Scrum Master to escalate to, who can also perform customer-side delivery performance analysis.

Built-In Failure Mode Mitigations

Sandbagging: small team size and Minimum Velocity alleviate the risk of sandbagging.

Team Packing: fixed Sprint Cost and and Sprint Length make team packing hard to hide.

Rate Card Manipulation: alleviated by fixed Sprint Cost, but can be easily changed as needed by issuing another Schedule A.

Incompetent Vendor: Alleviated by Sprints Paid Upfront. This is the maximum loss the customer will incur if the vendor signs the contract, takes payment, and immediately vanishes, or simply cannot deliver.

A Note for DevOps Teams

A DevOps team that is responsible for the hosting, uptime, incident remediation, enhancement, and deployment of all planned or unplanned work, must have a Minimum Velocity of 0. Any incidents, requests, or new Backlog Items that must be completed within the Sprint, that were not part of Sprint Planning, must also get 0 points. This is the easiest way to understand the distribution of work (items with 0 points vs items with points) and the completion rate of planned work, to give the PO an understanding of when the backlog will complete (and therefore the cost of the planned backlog items completed by the support team).

Put differently- a DevOps team that is 100% consumed with incidents and bugs for several Sprints, will have a stack of work records completed to show they’ve solved problems, but none of it will have been planned, so therefore they will have a Velocity of 0, meaning they will never be able to complete any of the work on the backlog. Such teams are typically better incentivized by a contractual Service Level Agreement (SLA).

Tips and Tricks

  • Add a clause for 50% payment at 50% MV – allow the team to fall short without giving up on the Sprint entirely.
  • Add a clause for double payment for completion of triple the MV – the savvy PO will ensure the top of the backlog holds more well-refined value than what the team is capable of delivering in a few Sprints. Unless everything happens to go right the first time with the vendor. In which case you’ll be happy to pay them double to get triple the value.

Loading