When we hear about focusing on value first, delivery early and often, there is rarely any mention of the cost of that delivery. Or anything about the customers ability to accept those early and often deliveries and actually put them to work earning that value.
In the must read book Product-Focused Software Process Improvement there is a paper, Value Creation by Agile Projects: Methodology or Mystery? a Conference Paper from Lecture Notes in Business Information Processing · January 2009.
We can learn a lot from this journal paper.
Business value is a key concept in agile software development approaches. This paper presents results of a systematic review of literature on how business value is created by agile projects. We found that with very few exceptions, most published studies take the concept of business value for granted and do not state what it means in general as well as in the specific study context. We could find no study which clearly indicates how exactly individual agile practices or groups of those create value and keep accumulating it over time. The key implication for research is that we have an incentive to pursue the study of value creation in agile project by deploying empirical research methods.
The platitude of we focus on value is just that - a platitude. And like most platitudes, it gives you a warm and fuzzy feeling inside, but provides ZERO advice in terms of actionable outcomes.
Value (business value of the software) has several attributes that need to be determined before the Value of the Value can be assessed as desirable
- What is the cost of acquiring that value?
- When will I be able to put that value to work to start earning back that cost?
- Over what period of time will I have to pay to acquire that value?
- Are there any recurring costs associated with acquiring that value?
- How do I account for the cost of acquiring that value and accounting for the Value itself in the larger accounting systems for the project being funded?
This is the FASB 86 problem with Agile Software Development. This is a capitalization issue for business. All those agile and #Noestimates platitudes need to come in contact with the reality of FASB 86 and other GAAP governance when spending other peoples money. Not much to date on that.
These are all finance and accounting questions, no coding questions. So in the end...
In the economics of writing software for money and producing the Value to the customer for that software, knowing the cost to acquire that Value, the time cost of money when producing that Value, and the planned arrival date of that Value versus the business need date of that Value all have to be known to some degree of confidence in order to make credible decisions.
Determining this information is called ESTIMATING.
No matter how often it is repeated the #Noestimates applicable to writing software for money - using other peoples money - it simply not true. It violates microeconomics of decision making, managerial finance principles, simple time cost of money accounting principles, and is a all around bogus idea.
Making decisions in the presence of uncertainty about future outcomes (value in exchange for cost) requires making estimates.
