Cost Accounting is a Problem for Agile (and Knowledge Work)

The more I work with project portfolio teams and program managers, the more I understand one thing: Cost accounting makes little sense in the small for agile, maybe for all knowledge work. I should say that I often see cost accounting in the form of activity-based accounting. Each function contributes to some of the cost of the thing you’re producing.

Here’s why. Cost accounting is about breaking down a thing into its component parts, costing all of them, and then adding up the costs as you build it. Cost accounting makes sense for manufacturing, where you build the same thing over and over. Taking costs out of components makes sense. Taking costs out of the systems you use to create the product makes sense, too.

Cost accounting makes some sense for construction because the value is in the finished road or building. Yes, there is certainly knowledge work in parts of construction, but the value is in the final finished deliverable.

Software is neither construction nor manufacturing. Software is learning, where we deliver learning as pieces of finished product. When we have finished learning enough for now, we stop working on the deliverable.

Agile allows us to deliver pieces of value as we proceed. Other life cycles, such as incremental life cycles or even releasing your product in short waterfalls allows us to see value as we proceed before the whole darn thing is “done.”

We might need to know about costs as we proceed. That’s why we can calculate the run rate for a team and see how our feature throughput is working. If we start looking at feature throughput and the cost per feature, we can put pressure on ourselves to reduce the size of each feature. That would reduce the cost per feature. Smaller features allows us to learn faster and see value faster.

Cost accounting has a big problem. It does not account for Cost of Delay, which is a huge cost in many organizations. (See Diving for Hidden Treasures: Uncovering the Cost of Delay in Your Project Portfolio to read all about Cost of Delay.)

This is one of the reasons I like feature sizes of one day or less. You count features for throughput and use run rate as a way to estimate cost.

I don’t know enough about accounting to say more. As I learn with my clients and especially learn about the pressures on them, I’ll post more. I do know this: the more we talk about the cost of a feature without talking about its value, the less we understand about how our software can help us. The more we talk about velocity instead of feature throughput, the less we know about what it really costs for us to develop our software.

Cost accounting is about surrogate measures (earned value, the cost of tasks, etc.) instead of valuing the whole. Agile gives us a way to see and use value on a daily basis. It’s opposed to the way cost accounting works. Cost accounting is a problem. Not insurmountable, but a problem nevertheless.

There are alternatives to cost accounting: throughput accounting and lean accounting. To use those ideas, you need to enlist the finance people in an agile transformation. As always, it depends on your goals.

13 Replies to “Cost Accounting is a Problem for Agile (and Knowledge Work)”

  1. This manifests itself in the consulting world. Clients want to sign a contract for X work @ $Y with a small % buffer. Agile consulting shops have to spin up a team (often a net new combination of humans with no known velocity) and get the work done for that $Y.
    The translation of story points to $$$ often falls to the project manager and often adds complexity where there shouldn’t be.
    Has anyone solved for this elegantly?

    1. Amber, thank you for that example. Marcus Blankenship and I wrote these two articles: Stay Agile with Discovery, and Use Demos to Build Trust. Martin Fowler has a terrific article: FixedPrice.

      The problem is fixing scope and cost and date is not agile. It also doesn’t make sense.

      BTW, instead of story points, do a discovery project where you deliver something in a couple of weeks and break all the features down into one-day stories. That will work.

      1. That requires selling not only your services, but Agile as a methodology in the sales process.
        I’m not saying it’s impossible, but it puts the onus on the Sales team to understand and accurately represent Agile to potential clients.

  2. And when you deliver those “pieces” of “value” as we do every 3 weeks on a large enterprise IT program ($450M), what is the “cost” to deliver that “value.”
    Without that knowledge, “value” itself cannot be determined. This is fundamental business cash flow management.
    For “agile in the small” the cost accounting is simple – FTE’s billed to the delivery of the “value.”
    But not answering “what’s the Value at Risk,” first before deciding that cost accounting is a waste is also poor business management
    It’s not your money, spend it like it is.
    Otherwise, we on the management side would consider that approach only when the project is de minimis, and have no concern about the cost.
    BTW throughput accounting and leans accounting ate still cost accounting. Like the No Estimates advocates renaming the term to suit the needs of the speaker does not change the principle, just the name.

    1. Glen, maybe I’m missing something. The cost for 3 weeks (or whatever the timebox is) is the run rate of the team(s), right? I agree, we should calculate run rate. We should know the “overhead”–what it takes to keep the lights on, etc.

      The part I’m concerned with is this: When we separate the costs of a feature (let’s start small and move up) to analysis because the PO is in a different org, and development because the developers are in a different org, and testers because the testers are in a different org, we have some notion of what it takes to deliver a feature. But, those individual costs don’t work the same way a cross-functional team works together. What about the discussion you and I have at lunch because we are still thinking about the feature and I have questions for you? What about the time it takes for us to decide what our team norms are?

      I would like to see accounting work on the team level, not the person level.

      When I’ve done something like this with other management teams, when we work on team-based activities, not personal activities, we often ask the teams to work on their throughput. That reduces the Cost of Delay, which affects the Value at Risk.

      Do you look at CoD when you look at Value at Risk?

      1. If everyone on the team is working on only one project, has no support responsibilities, never takes vacations or sick days or goes to individual training, the cost for the time box is indeed equal to the run rate of the team. For everyone else, there are details to be tracked. If the tax code and GAAP treated all expenses like one giant bag of white rice, then the details wouldn’t matter. But some products of knowledge work are tracked as assets, some as capital expenses, some as operating costs, and some are simply written off as waste with no salvage value. I realize that most programmers glaze over at this, just as most accountants glaze over when confronted with C++, but just as much of the value in code lies in error handling procedures that may never be executed, so is value created in making business records auditable.

        1. Dave, you are correct. Capitalization for agile is actually a big deal—when can you capitalize? That question makes the idea of an MVP (Minimum Viable Product) even more interesting.

          I do understand that vacation comes out of a different bucket. So does overhead. And, when finance people “run” the software folks by asking them to account for all the costs and none of the value, we don’t see how to capitalize differently.

          Maybe the issue is more about capitalization. If we seek to capitalize earlier, maybe there is less focus on time management (something I keep seeing in my clients). Their focus on time management (as a resource) prevents them from seeing flow of value. There can be flow of value in support as well is in projects.

  3. Great conversation and a great article, Johanna! I have found that a MVP as long as it is estimated as a range keeps the finance dept at bay. They do have to worry about FABS-86 and R&D credits among other things and no group is going to let a costly dev team work with an agile perspective that “we’ll get it done quickly, just trust us!” Also, I find that identified up front very rough t-shirt size estimates that the team buys into a great way for the team to plan for a range of iterations that could be regarded as the delivery range. From there, sales and finance should count on the worst possible case to the iteration after the max of the range. And if the team delivers earlier, EVERYBODY WINS!

    1. HI Ken, I do love ranges for estimation (or % confidence). And, since you mentioned MVP, if the team can optimize for flowing the work for releasing an MVP, that makes everything better.

      I’m teaching an on-site version of my product ownership workshop this week. I hope to have some insights (not discussing client particulars) after that. We will see…

      1. In my #tameflow I make heavy use of MMRs (aka MMFs) – which are slightly more meaningful for the financials. The MMR is the minimum thing that a client not only values (like a MVP, sort of), but it is the minimum increment that the client will actually pay for.

        So, with an MMR, you can account for the “plus” side of the reasoning, and not only for the “minus.”

        An MMR is a unit of financial value. A MVP is a hypothesis to discover problem/solution and/or product/market fit; a MVP is no good for counting beans. It is good to discover if you have a field with growing beans…

        If you can convince the accountants to use Throughput Accounting, this all becomes a storm in a teacup. Throughput Accounting can easily be transferred to Cost Accounting (for all and any reporting purposes) by any skilled accountant. [Don’t ask me how… I’m not an accountant… I delegate this to those skilled in the art.]

        In the Throughput world, the salaries of the team is considered (part of) the Operating Expense. No artificial attempt at allocating costs is done. You pay salaries whether or not the team actually “produces” anything.

        You can also quantify with Cost of Delay, or – in the throughput world – “Throughput Octane” and see how that impacts the bottom line.

        Also I have an issue with the thinking about “keeping the finance department at bay.” That’s not, in my view, how you build a superior performing organization. You must find inclusive approaches. Anytime you draw a border, you will have conflicts. People will fight each other inside the organization, rather than focusing energies on winning in the market.

        Throughput Accounting, done correctly, will get the finance department on board; as it gets on board anybody else.

        In #tameflow I evangelize about creating “Unity of Purpose” (at the organizational level; not at the team level). Throughput Accounting is one of the most powerful tools to get to that. Everybody will be rowing in the same direction, including the dreaded finance department.

        In my opinion, as long as you are using Cost Accounting to make management decisions, there is ample room to improve.

        1. Steve, you have a point about salaries: the company still pays the salaries, regardless of what the team produces. Even if management decides to outsource (make employees contractors in some way), the company still pays. Current accounting thinking for software says, “We’ll allocate salary as expense until we can capitalize the output.”

          Being able to produce something of value, regardless of what you call it (I’ll address what minimum is in another post) provides us different options.

Leave a Reply