Success stories and surveys support agile software development. In addition to anecdotal evidence there are little hard figures to guide our decision making. Here cumulative business value charts are used to describe the impact of agile and traditional choices to the bottom line. Focus is on visualizing the economic impact of individual agile practices and assumptions of their costs and profits.

A chart describing the cumulative earnings as a function of time is a basic tool for optimizing the return of investment, ROI. The line is higher all the time if we have multiple deliveries. It is still better if the more profitable increments are deployed the first. This advantage in time-to-market is clear also in the surveys. Double the results in half of the time assumes that earlier deliveries have business value and that the additional cost of more deliveries is small.

• It is not trivial to find minimum viable products that create value especially when organizations do not improve their businesses continuously but use large projects with non-negotiable late deadlines. Waste of the inventory of the partially done software is not as visible as the waste of tangible inventories.
• The cost of a delivery has been a show-stopper of agility. Business models were based on sales of new versions of software that were installed manually to each client computer. Each deployment package had to be tested and integrated manually. Without automation the costs can overcome the benefits of early deliveries.

The cost of change must be small if we proceed empirically and feedback directs our product and development process. Customers pay these changes when they create more value than the costs of delaying and implementing the the changes.

• Extreme programming proposes a set of practices like test driven development, re-factoring and pair programming that change the cost curve, cost of change, such a way.
• Waste of unnecessary features can be avoided by prioritizing product backlog items based on their business value and changing the order when appropriate.

Risks are an integral part of any design. In software development we do not commonly know what the users actually need and how we use  new technologies that create the results. The cone of uncertainty is high. Reports of more than hundred-fold effort differences are common. Sales, savings and profit estimates are so inaccurate that it is quite common to ignore them altogether.

•  Whole investment is lost if  we do a wrong thing or fail in the implementation
• Customers try to protect themselves by fixed price projects. Costs increase because vendors have to buffer their offers especially if penalties are used. Competitive bidding weight visible price or over quality and total cost of ownership. The bidding game sets customers and vendors against each other.
• Incremental deliveries make risks visible and adaptation is easier.
• Agile approach is a natural risk management system, but it often fails when appropriate action is not taken. Organization cultures must allow canceling and redirecting projects.
• Queuing theory and theories of variation can lead to improved practices in handling unpredictable situations.

Traditional mass production uses specialized lowest costs work force, rigid processes and invests in tools. It locally optimizes the cost of the tasks that workers do and is often blind about the required administrative burden.

• Cost of learning can be significant. It unavoidable when we do something new. Open workspaces, pair programming and shared responsibilities are agile practices that accelerate learning. It would be good if that could break Brook’s law.
• Cost of teamwork is minimized in a cross-functional team in single location. Wastes of relearning, transfer of work, task switching and delays are minimized. Software development has dis-economics of scale because a lot of communication and coordination work is required.
• Utilization rate of the specialist become easily low. To avoid that developers take part of multiple simultaneous projects which often leads to coordination chaos.
• Cost of motivation is difficult to estimate but essential part of working life. Leadership style has an impact on the engagement of team members which may result in more value for the business.
• Traditional big front end design tries to minimize the cost of rework but real life shows that a large amount of work is needed to correct the bugs, integrate the components and deliver what users actually need.

Traditional and agile approaches have different assumptions of the relative costs of the parts of software development. Agile assumes high risks, high integration and collaboration needs, low predictability and low cost of change.