Accepted Value Costing

This discussion forum supports the "Show Me the Money" AgilePhilly presentation of April 17, 2018 during which the attendees were introduced to Accepted Value Costing, or AVC. This is a Lean-Agile extension of two-stage activity based costing developed by Dave Hughes starting in 2015.

Cost accounting structures are complex, deeply entrenched based on long years of hard experience, and effective in satisfying executive decision makers. Ironically, they are very costly, as well. Project-based costing continues as the management accounting approach of choice within Agile transformations, even after two decades of proven success with Lean and Agile alternatives. In addition to the costly overhead, project-based costing contributes to delivery unevenness leading to waste mostly in the form of multitasking. It contributes to a mindset of anti-patterns resulting in overburdening of the people involved.

There is an easier way. Accepted Value Costing is a field-tested approach based on activity-based costing techniques adapted to the Lean-Agile paradigm of fixed cost + fixed time + variable scope value stream delivery on a cadence. It overcomes the valid reasons for resistance by financial and accounting departments to change in favor of pure activity-based costing, Beyond Budgeting, and Lean accounting. It is a field-tested integration approach which favors enabling Lean-Agile decision making over the mechanics of budgeting, time reporting, and variance tracking.

AVC is a permission-giver. It is lightweight, effective, and focused on practical decision making favoring delivering value early and often.

Over the past six months or so, AVC has been applied in a variety of situations, both experimental - "Let's see how it might work" - and practical - "Let's make decisions based on it." The following summarizes some very interesting results.

Discoveries:

1. AVC forces the explicit definition of a credible feature set and, therefore, promotes a desirable pattern of refining a portfolio hierarchy. Product (strategy level) and story (tactical level) are not enough.2. AVC actually protects the product owner from interference by executive management by empowering him, exclusively, to make value-based decisions for fast flow, fast feedback, and fast learning. The product owner's sales talk with executives should focus on the risk-reward of the product/service at the strategic level. The PO asks for executives to place their bets on that basis, preferably in reasonably small batches – certainly smaller than tens of millions over a year. AVC empowers the PO then to take action within a radically decentralized decision-making context, for the benefit of customers, teams, and executives, in that order.3. In this case, revealing that teams used stories to reserve capacity for non-product related work items is a good thing. Using the all-in, FixedTime-FixedCost paradigm, stories should NOT be used to “track time and effort.” AVC drives this out, and reapportions indirect labor expense to reveal relative value accepted.

The first rule of funding club is you don’t talk about funding club.Fear level can be very high if the PO assumes that #2 has no differentiation. The fear-driven assumption is that any talk about money can be – will be - misused by executives to push or punish teams.

John Voris, lead coordinator for AgilePhilly, reached out to me in June with a reference to Scott Fawcett's use of Earned Value Analysis (EVA) for measuring customer value. Scott's comment is on the thread in the "Agile & Lean Software Development" LinkedIn group at https://www.linkedin.com/groups/37631/37631-6408061366376165376. He says: "For many of us, we have a fixed budget and an expected release date (for example, this is a greenfield development effort we can't release to the public, our customers, it's small bits and pieces). That's not saying we're not getting our customers, under NDA, involved in UX design, development, beta testing, etc. But, without simply measuring the "size of their smile" (that will not suffice for my CEO paying the bills with an expected outcome in the form of a new revenue stream), how do you measure the value? In lieu of that I measure stories completed per sprint vs. our plan, because the plan indicates if I'm on track (budget and schedule). And I measure EVA because it brings the cost variable into the equation (did you complete the functionality you planned and did you do that on cost plan)." John wondered how AVC works relative to EVA.My detailed response was as follows:

1. The Scrum Papers include a paper from 2005 by Barton, Schwaber, and Rawsthorne entitled Reporting Scrum Project Progress to Executive Management through Metrics. In this paper, in the “Executive Dashboard” section, the authors try to make sense of “Business Value” as a sort of S-curve graph with the X axis as sprints and the Y axis as money; this is EVM. They call this the “business value burnup.” Since it requires a WBS, it’s obvious that this didn’t survive for a good reason. Rawsthorne branched out with other papers on his “earned business value” or EBV, including detailed calculations for determining value earned. Again, this is classical full-accrual project accounting, based on a WBS. If you lift the hood, it’s EVM inside. 2. Mr. Fawcett says he “measures EVA because it brings the cost variable into the equation.” EVA is an estimate of expected economic value which, itself, is a highly fluid concept. Note that Scott’s approach requires a cost plan, so it will be similar to traditional approaches of approximating “worth”. See #1, above.

Bottom line: these approaches are one way to feed decision making, but they are heavy weight and they carry a significant measure of value estimating; think Kano.

AVC is lightweight and, because it’s theory is based on two-phase activity-based costing, it supports decision making based on actual value accepted, proportionally allocated to valid cost pools.

Everyone should note carefully that EVA is dependent on cost of capital as a primary attribute. The use of EVA is hard to justify when indirect labor expense constitutes the vast bulk of the cost for software development, especially when inspect-and-adapt behavior patterns predominate. To be clear, capitalizing software "product" has very narrow and rather complicated constraints. FAS86 has been referenced many times in many papers. Consider the following: Statement of Financial Accounting Standards No. 86 http://www.fasb.org/jsp/FASB/Document_C/DocumentPage?cid=1218220127... “FAS86” August 1985. Note well: This applies only in the case where internally developed computer software is to be sold, leased, or otherwise marketed as a separate product or as part of a product or process. It differentiates between R&D costs and production costs that can be capitalized.

AgilePhilly Day Oct 22, 2018 attracted a small but extraordinarily intelligent group of attendees to "Product Owner Empowerment through AVC: fast funding flow, fast value feedback, fast learning." Thanks very much to all the attendees - your participation was inspiring!

Our AgilePhilly events are those with the Liberty Bell Logo. And other locations and cross-postings of other User Group events in the Philadelphia, Bucks County and Jersey area. . . are denoted PB&J . . . So please tell us of your event to list here alongside ours.