One of the main points he makes is that whatever product feature or function is developed and delivered it should have two valuations:
- A top-down allocation from sponsors or those making the investment in the project
- A bottom up estimate of effort [read: cost] to develop
Highsmith makes the oft described admonition: the top-down valuation should exceed the cost to develop. Said another way: 'quality' is often defined as getting more for your money than you might have expected.
Of course, in my experience, it can go the other way: the cost to develop exceeds the value allocation. In fact, it often goes the other way. Sponsors, users, and product masters are--as a group--more optimistic than project managers. Consequently, they underestimate risks, overestimate benefit, and most often underestimate cost. As a group they are afflicted with optimism bias.
What then?
That's what I call the project balance sheet risk: there's a gap between resources needed and resources expected to be provided. To close the gap, the project manager takes a risk with an intent to find a way to deliver.
In the webinar, one listener asked the obvious question, which I paraphrase: Where does a credible dollar figure come from for the value side of the equation?
Highsmith seemed not to have an answer ready with which he was comfortable. He said, in effect, value assignments are made by allocation, but he had no rules or protocols to offer about how to go about this.
What he should have said was:
Of course, there's no universal definition of value; rather, there're many definnitions of value, much like there're many definitions of quality, no one of which is 'the' definition.
That said, it's a matter of environment, experience, competition, history [reference projects] that all combine to provide a value judgment that is a few parts rational [that, is facts] and a few parts emotional or qualitative [that is, the art of the situation].
It should be obvious: there's no formula for getting a value judgment right. The Nano failed and the iPod soared. It happens.
But also: the farther down the WBS you get, the less valid is any value judgment. What you get is more of an ordinal valuation: "this is worth more to me than that".
And, you get anchor bias: "that's what it cost last time, so that's what it should cost this time". The first one to throw down the anchor, whether the value figure or the cost figure, has the negotiating advantage.
However, the power of agile is that this judgment is frequently revisited, and in the revisit process there is opportunity to evaluate, calibrate, and test the value judgment.
And by the way: I'm talking about the business value of the investment, not the business value of the opportunity. Highsmith didn't talk about it, but there's actually three parts to every project econometric:
- How much a sponsor wants to pay
- How much a project needs to succeed
- How much the business expects to earn from the investment
Bottom line: There's an art [value] and science [cost estimating] to be reconciled by iterative reexamination as progress accumulates. Of course, this is not exclusive to agile; every methodology includes this idea. It's just that agilists accept it as a centerpiece of agile management.
