Business Value Disadvantaged

Despite the current emphasis on benefit in stakeholders’ minds, there is still a focus on cost management when it comes down to the day-to-day work in modern software development. This works counter to underlying assumptions in modern development methodology. We motivate a more deliberate approach to benefits management during development, but it is the combination of cost and benefits management that saves the day. 1.1 A Paradoxical Emphasis on Cost Modern development ideals focus on business value. In agile management and development, the mantra is ‘Value for the customer’. The product owner is involved along the way and backlogs are prioritized, with the best intent to produce benefit. Yet, it seems that, in many information technology development projects, there is still bewilderment regarding how exactly customer value should be expressed in process decisions. Routines for cost estimation are common, and cost estimates and productivity outlooks are routinely updated and monitored. Earned value measures and burndown charts can tell you when to start cutting back the scope. However, chances are that benefit is treated haphazardly compared to cost [5], which is a paradox, given the focus that business value is supposed to have. This book promotes the idea that one should treat benefit with at least the same systematic attention as one treats cost. Moreover, benefit and cost estimates should be combined to give estimates of benefit over cost in a manner that enables benefit/cost-driven development. The absence of an explicit treatment of benefit can lead to decisions based only on cost when one actually wishes to make decisions based on business value. It would be good if one could use a burndown chart to cut or promote functionality on the grounds of benefit rather than cost only. 1 © The Author(s) 2021 https://doi.org/10.1007/978-3-030-74218-8_1 J. E. Hannay, Benefit/Cost-Driven Agile Software Development, Simula SpringerBriefs on Computing 8, 2 1 Business Value Disadvantaged Further, one is in danger of perceiving an expensive piece of functionality as also representing a lot of benefit. This fallacy piggybacks on the folkloristic common law of business balance [13], that is, the principle that one cannot pay a little and receive a lot: one should have to pay more for more of a product (ten bottles of wine) than for less of that product (two bottles of the same wine). The principle applies to software development as well; it is reasonable to expect to pay more for more software than for less software. However, more software does not necessarily provide functionality that delivers more benefit. The confounding of cost with benefit transforms the reasonable principle above into a fallacy. Clearly, then, there is another dimension to take heed of, in addition to the amount of software or even the amount of functionality. Thus, unless one has a sensible measure of benefit for one’s backlog, one will not be able to manage construction with respect to benefit and will potentially regress to merely producing amounts of software instead. 1.2 Taking Control . Management based explicitly on benefit, in addition to cost, implies steering development activities toward the intended goal. It should also help you to avoid phenomena such as the escalation of commitment to a failing course of action in general [15, 16], and in software development in particular [7, 8]. This phenomenon involves people continuing to pursue activities in the face of clear signs that the activities are not achieving the goals, due to an (often emotional) attachment to the effort already invested in the activities. Related to this are the sunk cost effect and the Concorde effect, wherein a rationale is created to continue an ostensibly failing course of action, with the argument of not wasting what has already been invested [1]. A business strategy with plans that express development metrics explicitly in terms of business value and cost is a valuable tool to counter such effects. Suppose the strategy states that development will cease as soon as potential business value is no longer produced. Suppose, also, that metrics are in place that keep track of not only the amount of software produced (and money spent), but also the amount of benefit that the software is expected to give. Then, it should be impossible to enter into the realm of wilfully producing waste without at least someone in the steering group noticing.