What is the best way of accounting for costs as different types of expenditure with agile development teams? This is a question that comes up every now and again, particularly during more significant transformations. I usually respond by explaining that I’m not an accountant. It’s also not a topic I particularly care about.
However, I heard Johanna Rothman make a comment which struck me during the recent Drunk Agile Holiday Special. At least I’m pretty sure it was Johanna! I now understand why I don’t care and can give a much better answer.
Value and Cost
Before I get to that though, it’s worth reiterating one of the underlying principles behind agile software development. That is a focus on value.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile Manifesto Principle #1
I often say at some point towards the beginning of a new transformation that increasing value is infinite while reducing cost is zero-bounded. This comes up when I get a sense that an organisation views Agile as a means to reduce costs. After all, it’s associated with being more Lean, isn’t it?
I explain that an agile approach might actually cost a little bit more. However, that should be a relatively small increase in cost compared to the potentially significant increase in value. In other words, it’s better to focus on being more effective than more efficient. Or to paraphrase Russell Ackoff, it’s better to focus on doing the right thing, rather than doing the thing right.
Revenue and Tax
Let’s go back to how to allocate costs to different types of expenditure for agile development teams. The usual reason for this is to minimise tax liabilities. After all, minimising tax will increase profit. As a result, organisations try to design their processes and practices to make it simpler to minimise tax. That’s fairly easy in a traditional, large batch, stage-gate process. Different stages can count as different expenditures. The challenge is that it’s not so easy with agile teams who focus more on collaboration and flow.
What Johanna said is that it’s better to focus on increasing revenue, than reducing tax. Just like value and cost, increasing revenue is infinite while reducing tax is zero-bounded. Thus increasing revenue is the thing which should drive decisions on ways of working, and not minimising tax.
In other words, don’t worry about it. That’s the best agile accounting approach to CapEx and OpEx. Instead, your real strategy and how you are going to deploy that strategy is what is going to have the maximum impact.
Is this a false dichotomy? It’s possible to drive decisions based on both increasing revenue and reducing tax liabilities.
The other one is a matter of prioritisation. You need to first chose the right thing to do and then do it right. If you mess up the former the later doesn’t matter. And often if you mess up the later enough, the former also doesn’t matter. So you actually need to focus on both, not one or the other.
Hi Russell!
You’re right, it’s not entirely black and white and either/or, but it is a trade-off that I would say too often tends towards wanting to minimise cost, and would be better tending towards maximising value.
Regarding prioritisation, that requires an estimate of value, and just like estimating size, or time, it’s usually wrong! The alternative is to quickly deliver small (right-sized) increments of work to get feedback on actual value and iterate based on that feedback. If it is valuable keep going. If it’s not, then pivot. Thus the focus is on learning what the right thing is, as effectively as possible. Paradoxically, you focus on outputs over outcomes in order to maximise outcomes. Dan Vacanti has a nice write-up of this approach here: https://medium.com/@danvacanti/note-this-is-a-very-early-unedited-version-of-this-article-c3995870a975
Karl