Dave, You may have described the difference between product development and services. In the product world, no matter the domain I'd say, budget, delivery dates, minimal capabilities are all involved in the assessment of "value." In a services domain this may not be as important. I personally don't like analogies, so the umbrella thing is a non starter. As far as uncertainty, managing in the presence of uncertainty is the norm of most domains. For Neil to conjecture that those managers are seeking certainty is simple naive and misinformed. We are required by acquisition regulations to submit monthly a Monte Carlo assessment of cost, schedule, and technical performance estimates of upcoming deliverables. Reference Class Forecasting, stochastic models, and similar approaches are the basis of our management processes.

David, This came from a "lame" contributor to a LinkedIn forum with the self-proclaimed title The #1 Group for Project Managers. When another participant called her out as a troller, and simply looking for a fight, he was blocked. She is in the UK, and after a while I figured out was one of those provocateurs who loves to stir things up with stupid and idiotic comments. But it provides me with more support for a safety campaign at a nuclear weapons plant I worked at... "Don't do stupid things on purpose." She certainly as doing stupid things on purpose.

Dave, The analog proffered that "agile is like an untended garden, with emergent plants," is a bad analogy. The untended garden is a weed patch. And I'd strongly suggest that was not what was intended. Saying bad analogies is not good process. Good analogies, provide good guidance, but analogies don't. It's that simple. If you're going to communicate an idea, I'd think you'd want the idea to be based on some credible notion. Actually poor usage, is just that poor usage, and poor usage needs to be pointed out as poor use of the tool. This is not the tools, fault, but there should be no excuse for the poor usage of a tool. To use an analogy "it is a poor workman who blames his tools." So address the problem of poor analogies. Remembering a poor analogy serves no purpose.

I would say that like poor statistics, poor metaphors need to be distinguished from good metaphors before they are of any use. The principle of metaphor, like the principle of statistics, must be validated if it actually going to communicate credible information.

Shim, My suspicion is, having worked on a couple large ERP projects with agile, is the cost accounting is all Level of Effort. The customer, knows the cost by head count. They monetize the project by the labor commitment across the period of performance. They then use SP's as the measure. This of course fails to measure the "efficiency" and "effectiveness" of that labor force in the way Earned Value would.

Patrick, I had an interesting conversation around this with Alistair Cockburn over lunch when he was visiting Boulder. ▪ SP's are not monetized, so connections to the customer's Total Allocated Budget (TAB) can't be made. ▪ SP's are not adjusted for varying capacity for work - the Aleatory uncertainty. ▪ Agile project's have no margin, management reserve, or contingency, which of course is a violation of every good PM process for protecting the project from irreducible uncertainty. It would be interesting to see actual data on the number of SP's that get pushed to the next iteration. This data is available on all EV based projects.

All, As John says, you have to take the paper with a grain of salt.