Unless you're building sofwtare as a hobby, someone is paying you to do that work. Those paying aren't likley doing it as a hobby either. They have some expectation of getting their money back sometime in the future. Somewhere in the discussion of writing software for money, the notion of writing software for money was lost.
Those with money pay those with software writing capabilities to produce products that can be sold or put to use to create a value in return. Along the way was a disconnect that software is an end in itself. That the needs to developers trumps the needs of those providing the money for the developers. That those spending the money get to say what they'll do, how they'll do it, or what they won't do with that money.
Writing software for money as practiced in a sole contributor paradigm provides nearly infinite flexibility on requirements, cost and schedule forecasting, and the current notion of making business, programmatic, and technical decisions in the absence of estimating the cost and impact of those decisions.
When that paradigm leaks into a larger domain of producing a return on the investment from that cost, there are two varaibles that must enter every conversation. The Value generated by expending a Cost to produce an assessment of both those variables.
ROI = (Value - Cost) / Cost
A Value at Risk is one approach to assessing what processes should be in place when spending othe people money. The larger the Value at Risk requires a larger discipline of managing both the Cost and Value. There are many paradigms of Agile and the domain and context of software development, or any project for that matter, is important to assess before stating any method is applicable outside the ancedotal domain of the speaker.
The first assessment is always Value at Risk. That is, what is the cost of making a wrong decision? This is the basis of Microeconomics. This is the oppotunity cost assessment of decision making.
Microeconomics studies the behavior of individuals and small impacting organizations in making decisions on the allocation of limited resources. Cost, schedule, and technical capabilities are certainly a limited resource.
Those conjecturing decisions can be made in the absence of estimating the cost and impact have yet to show the viability of those ideas in practice, at least outside small projects with low Value at Risk.
The book The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, Barry Boehm and Jo Ann Lane is a good bridge book between small low value at risk agile, Scaled Agile for Enterprise, and the full up formal DOD 5000.02 acquisition processes that are trying very hard to move into the agile domain.
The book starts with four principles:
- Stakeholder value-based guidance
- Incremental commitment and accountability
- Concurrent multi-discipline engineering
- Evidence and risk-based decisions
There are extensions to these principles:
- Risk Meta-Principles of Balance - balancing the risk of doing to little and the risk of doing too much to find the middle course sweet spot.
- Theory W (Win-Win) theorem - in which a system will succeed of and only of it makes winners of its success-critical stakeholders.
- System Success Realization Theorem - in which making winners of success-critical stakeholders requires:
- Identifying all of the success-critical stakeholders.
- Understanding how each stakeholder wants to win.
- Having the success-critical stakeholders negotiate among themselves a win-win set of product and process plans.
- Controlling progress toward the negotiated win-won realization, including adapting it to change.
