...the Scrum Team is acting as a vendor to develop and deliver the content of a Product Backlog that they ordered using High Value First. The Scrum Team realizes its value through a fixed-price agreement or perhaps a shared-risk Development Partnership whereby it receives a share of the client’s profit. There is usually a short-term profitability horizon, as is typical with fixed-scope agreements.
✥ ✥ ✥
It doesn’t make sense to spend time developing increments that cost more than they’re worth. The client is the next link down from the Scrum Team in the Value Stream, and it is interested in realizing value for itself from an accumulated, fixed number of Product Increments delivered from the Scrum Team as vendor.
The big picture is this: many agreements between vendors and clients need to look far beyond the horizon of certainty into the future. That Scrum works in Sprints and has a flexible Product Backlog adds the possibility of a flexible pay-as-you-go engagement in addition to traditional fixed-price, fixed-scope agreements. Dealing with the far future can be risky business, but sometimes decision criteria become more clear and crisp closer to the point of delivery than when drafting an agreement far in advance. Both the vendor and the client want the best value from such an engagement. The vendor’s value comes primarily from the engagement income, and more subtly from the goodwill and reputation that it can develop both for its own sake and for securing future engagements. The client’s value comes through the product that the vendor builds for it, whether from services the product offers to the client’s end users or from sale of the product to customers further downstream. The agreed-upon price that the client pays the vendor reduces the client’s value. There are several approaches to such an engagement that reduce risk or increase profitability more or less to the vendor and the client. Perhaps the dominant consideration is whether both sides hold the agreement to be fair: that is, neither side has knowingly gained value at the expense of the other.
Because of High Value First, we know that value (such as net present value) to the client of each delivered Product Increment drops monotonically over time. With perfect foresight it might be possible to identify the exact Sprint that corresponds to the point of diminishing returns: any development beyond that point would amount to overproduction and would create waste for the client. However, it is difficult to predict that point at the beginning of development. On the other hand, we can identify the decision points up front: they are the Sprints, which can be continuously evaluated for their Product Increments for profitability.
While an early termination penalty in lieu of full payment could reduce both the client’s gross expenditure and net vendor income as well, forcing the vendor to take delivery of and pay for the full feature set also creates ill will. And while a pure pay-as-you go arrangement could optimize the client’s value for cost, it also reduces potential net income to the vendor. However, it also frees the vendor for other engagements whose profitability may be higher than what they could gain by forcing the current client to pay an early termination penalty. The vendor still suffers a small opportunity cost from being idle between the termination of the current agreement and the start of work with a new client. If it is a fixed-cost, fixed-scope agreement, the vendor saves nothing by early termination and is likely to take delivery on those Sprints yielding marginal value, “just in case.” However, the client may ultimately feel the value recovered from the product wasn’t worth the price. The vendor receives full price in this case, but the client may view the vendor as having taken unfair advantage of the imperfect foresight (i.e., that the late product increments would be of low value).
Therefore:Stop development when the cost of continuing exceeds the benefit that the client enterprise will receive from the development.
✥ ✥ ✥
The vendor works to deliver to the client as long as ongoing work continues to increase the overall value (such as net present value) of all Product Increments.
In addition to ensuring that value to the client doesn’t decrease, also make sure that stopping development at these points won’t cripple the vendor’s profitability or value. The client may agree to pay a termination fee to the vendor in the event that it terminates the agreement early, but the client still pays much less than if it had pursued the agreement to the end. One can argue in all fairness that such a fee covers the vendor’s opportunity costs while lining up new business. It is best that the vendor ensures, from the beginning, that each deliverable (Sprint) has positive value to the client, so that the client doesn’t put the vendor at risk over the life-cycle development.
For an example, see “Change for Free and Money for Nothing” in [1] (Chapter 8, ff. 193), that describes a pay-as-you-go contract where the client negotiated the right to terminate the contract at the end of any Sprint—as long as they paid 20 percent of the cost of remaining development. The client paid $3.2 million for a product bid at $10 million and got it 17 months early, thanks to incremental delivery and being able to stop development when the feature set was complete. Furthermore, the client also used Change for Free to redirect some of the work into areas of higher value. In the meantime, the vendor, who had set up the contract to give a profit margin of 15 percent, ended with a net profit margin of 60 percent. Released from the contract early, the vendor was able to pursue additional contracts instead of having to wait 17 months to do so.
This pattern focuses on the benefits from the ever-growing insight over time into the profitability of a previously agreed feature set in a Product Increment. See also Change for Free, which capitalizes on the enterprise’s ability to better define Product Increment functionality as time goes on.
Having gained confidence from the success of short-term engagements with this safety net, both vendors and clients are more likely to take higher risk through a Development Partnership.
The Money for Nothing and Change for Free concepts originated in a class Jeff Sutherland conducted in the Netherlands in 2006.
[1] Jeff Sutherland and J. J. Sutherland. “Change for Free and Money for Nothing.” In Scrum: The Art of Doing Twice the Work in Half the Time. New York: Crown Books, 2014, Chapter 8, ff. 193.
Picture credits: Shutterstock.com. Solution sketch courtesy of Geir Amsjø.