How do we account for our software development efforts in an agile environment? This question comes up over and over in finance departments in all industries. As software investments continue to increase, and development teams adopt new methods of production, like agile, the accounting guidance developed in the ‘80s and ‘90s can seem foreign and lacking in application to today’s environment (ASC 350-40 and SOP 98-1 for Internal-Use Software and FAS 86 for Software for Sale or Lease). Fundamentally, the language of the guidelines was written when waterfall methods were predominant and tend to focus on the idea that software development progresses linearly with stop gates separating phases, just like a perfectly constructed Gantt chart. On the surface, this doesn’t seem to jive with agile methods which are more continuous and iterative, and focus far less on defining a particular phase with stage gates. This discrepancy often leads to one of the following negative consequences (in descending order of severity to the business):
- The blocking of agile adoption on the account of finance.
- The decision to avoid accounting treatment altogether to avoid dealing with complexity.
- The implementation of over-engineered processes (typically timesheet based) increasing overhead and/or decreasing utilization and impacting the relationship between finance and software development teams.
The first issue above seems an absurd thought, but it happens more often than you might think. If it is believed that agile processes will have a positive impact on productivity and business performance, blocking them because they don’t synch with perceived financial reporting/documentation needs means that finance is having a direct, negative impact on the business. While it is always true that every function needs to work to integrate with finance, as we discussed in a previous post on finance’s role as communicator, it is incumbent on the finance department to understand the workflow of, and integrate with, various functions.
The second issue above is almost the direct opposite of the first. Instead of exerting a strong force, finance simply avoids the issue altogether. The upside here is that agile practices are adopted (again, assuming they are the right methods for the business), but the downside is obvious. There is by definition a lack of finance integration with software development, reducing proper reporting as it relates to financial guidance and impacting the detail by which management and external stakeholders can view the business.
The third option tends to be where many businesses reluctantly end up. They set up a detailed timesheets system, often with onerous rules on time allocations and definitions, or perhaps require developers to somehow know the financial guidance when classifying their time, and then do a number of data merges in excel. At its best, this is a minor nuisance across the board with some risk in errors given excel based merging and reporting. At its worst, this results in significant wasted time and a very poor working relationship between finance and software teams.
Understanding the guidance behind the guidance
In order to address the issues highlighted above let’s reduce them down to basic principles and build back up. The fundamental challenge is a question of cost accounting and classification under the premise that much of software development efforts are investments in assets, not simply operating expenses. A capital expenditure is an investment in an asset that has material benefit to the business for more than one year. For the purposes of accrual accounting the initial ‘transaction’ simply adjusts cash balances down with an increase in long-lived assets, not expenses as those are amortized through time.
Clearly, when a company invests in developing software it typically intends to use it or sell it over a longer horizon than a year, and it will almost always meet the materiality thresholds a company requires. So, let’s analogize the phases of software development highlighted in the literature to a company investing in a more historic fixed asset like heavy machinery.
SOP 98-1 provides details on three phases of software development; preliminary project stage, application development stage and post-implementation/operation stage. The first is summarized as evaluation of alternatives and essentially making the case for a path forward. The second is fundamentally the actual work, effort and capital spent to develop the new software. The third is the maintenance, training and other post-implementation expenses. The literature says that expenses should be expensed as incurred in phases 1 and 3, but in the actual development of the new software functionality during phase 2, expenses should be capitalized.
Now, analogize this to a company investing in machinery for production of its primary goods. The company goes through a process of evaluating what to purchase and all of the potential alternative options. This is all pre-decision to invest. But, once they make the decision on their direction, they are fundamentally moving into investment stage. Once they have the machinery installed and operating, all of the training and ongoing maintenance to keep the machinery working through time are expensed as incurred.
So, the language of SOP 98-1 is really just a restatement of basic capex accounting in the first place. While waterfall methods tend to align stage gates to these phases, it’s not really the underlying logic behind the guidance. The guidance is applied irrespective of process.
Application to the agile environment
So, the chief issue comes when finance takes the guidance and explicitly puts it into their perceived chronological order (which is of course a natural thing to do), to which software teams say, “we might do all of those phases in each sprint…we can’t tell you that one sprint we are in one phase and the next in another.” This is typically where conversations veer towards one of the negative consequences highlighted above (particularly one of the first two).
But, if the next question is, “are you able to classify your work regardless of when it’s executed into these groups?” The typical response would be, “yes, of course we can as we already essentially do that with our user stories!” The basic idea is that in many cases, the development teams are already producing 90% of what’s needed for finance in their project management workflow applications.
Now, this is not to trivialize that the two functions need to solidify some additional decisions and processes (the remaining 10%), but the bulk of the complexity is removed right up front.
While there are a few different routes to go from here on process, the one we see often as a very easy solution is to view a software asset with versions and use versions to peel off phases 1 and 3. So, for instance, let’s say one of the assets a company is working on is called “Amazing Application for Customers” (AAC). The product development team might separate the versions of this into the following buckets:
- AAC- Evaluation
- AAC- Versions (ie 1.0, 1.1, 2.0 etc.)
- AAC- Maintenance
In any given sprint, the AAC team could work on the current version, but also include efforts on evaluation and maintenance (the reality is the evaluation is often irrelevant as in many cases it is completed in advance of the team being formed, but maintenance will always be relevant). Any efforts that are related towards fixing existing features fall in maintenance and any new features fall in the versioning. There are different ways some companies can address this, but the general idea is the same in all.
So, by simply engaging and understanding the agile development process, we now have a very simple way for finance to classify what work is capitalized and what is expensed as incurred. You simply pair this up with the financial attribution method (which, may or may not require timesheets) and you have your accounting process built directly into the team’s agile process! Not only are you measuring it, but you now have extremely useful insights into the financial consequences of technical debt through basic ratios of maintenance to versions through time. Finance can now be a much better partner to the development teams and a far better communicator to external stakeholders. Ultimately, that’s the goal of agile accounting, to help finance be a better partner to software development teams.
Additional Reading:
Dan Greening of Senex Rex has a very thoughtful piece on agile capitalization which highlights some similar themes discussed here as well as items discussed on financial attribution.
Pat Reed an enterprise agile transformation consultant has also addressed this topic at length and summarizes some of the blockers (including finance) inhibiting agile adoption here.
