Comprehensive software reviews to make better IT decisions

How to Stop Leaving Software CapEx on the Table With Agile and DevOps

raditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure (CapEx) dollars on the table.

money on the table

It should come as no surprise that most Agilists care more about software development than accounting. In many organizations the difference is critical. CapEx is capital spending on investments in the company’s future, such as new infrastructure, capabilities, and software. OpEx is operational spending related to running what you have built. Most importantly, CapEx is a clear signal of how much a company is prepared to invest in its future. Software development investment is also an unambiguous sign to industry and investment analysts that the company is competitive in the digital economy, which drives investment.

Traditional accounting leaves software development CapEx on the table

Software development costs have traditionally been capitalized, while research and operations are operational expenditures. The challenge has always been the myth that operations is only bugfixes, upgrades, and other operational expenditures. However, research shows that most post-release work on developed solutions is the development of new features and changes to support material changes in the business. While projects could bundle some of these changes into capital expenditure, much of the business-as-usual work that goes on leaves capital expenses on the table because the work is lumped together as maintenance-related OpEx.

Here comes Agile…

The use of Agile practices is the tipping point between project-centric and product-centric delivery. If your organization is still doing project-based Agile (Wagile, WaterScrumFall, or Fragile, as some of the more cynical Agilists call it) your accountants can carry on as if nothing has changed. The shift to standing product teams and DevOps shatters those comfortable boundaries, leaving delivery leaders scrambling to account for CapEx versus OpEx.

Agile and DevOps practices are not the problem; they are the solution

Agile and DevOps are often thought to be “breaking” accounting. The truth is that they hold the key to unlock the previously lost software CapEx – in particular, the practice of building a functionally decomposed backlog of features or user stories classified by the type of work. For example:

1 - A. Cockburn, 1999

Tag them all and the accounting takes care of themselves.

Breaking the boundary between Dev and Ops unlocks additional CapEx

Capital work done in operational use of the software is not only the implementation of new features. DevOps engineers are charged with building infrastructure as code – converting manual processes to automatically executed software. This fits the definition of software for internal use laid out in the Generally Accepted Accounting Principles (GAAP). This not only makes the company look good financially but also gives you a new way to make the case for funding from a pool of money traditionally inaccessible to operational software teams.

Success requires disciplined backlog management, roadmapping, and metrics

Using your product backlog to identify teams’ CapEx and OpEx work requires discipline:

You do not need to track time!

Task-level time estimates can be a valuable tool to help Agile teams build discipline. Unlike Waterfall, you should not need to do role-based time tracking to do Agile accounting. Story points are a useful Agile estimation and measurement tool that allows you to abstract out time while still accurately measuring the work you deliver. The key consideration is that you can only capitalize work that has been completed when you release it to production. Because the type of product backlog item defines whether it is CapEx the accounts can readily capitalize with a short list of items:

  • Full-Time Team Run Rate (salary, you should know this)
  • Contract Run Rate (contract $, you should know this)
  • Sprint/Release Length in Weeks (you should know this)
  • % CapEx (you should tell them this)
  • % Idle and Administrative Time (accounting should have defined this for full-time employees)

Or:

Equation: (Full Time Run Rate – Full Time Run Rate x % Idle and Admin + Contract Run Rate) x % CapEx * Sprint/Release Length in Weeks over 52

Here is an example using story points:

The advantage of this approach is that it allows you to ignore variations in velocity and release cadence between teams, which reduces your administrative overhead to simply reporting whenever you happen to release.

YOU MUST WORK WITH ACCOUNTING!

I prefer not to use all caps, but every rule has an exception. Every finance department defines how the organization will apply the GAAP to their financial operations. Agile creates the opportunity for change and more accurate tracking of capitalization. The decision to take advantage of this and how to implement it lies with the finance department, not IT.

Our Take

Agile represents a golden opportunity for organizations to manage software CapEx versus OpEx expenditures accurately and effectively. If you have implemented Agile, it is time to engage with accounting to define how you can take advantage of the opportunity created by product backlog item-level capitalization.


Want to Know More?

Do you need help getting started? Book a call for yourself and a partner from accounting to discuss how to make this work in your organization!

Visit our COVID-19 Resource Center and our Cost Management Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019