Traditional 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.
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.
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.
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 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:
Literally “a promise for a conversation” (Cockburn, 1999), a user story is the most commonly used artifact for organizing work in Agile.
A story that is too large or complex and cannot be estimated without prior time-boxed investigation.
The story is used to add functionality that enables users to do something they haven’t done before.
The team need to evaluate competing innovative approaches to automate a process.
The story guides refactoring that improves the performance of a production system.
The team needs to investigate the source of intermittent failures in a production system.
Tag them all and the accounting takes care of themselves.
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.
Using your product backlog to identify teams’ CapEx and OpEx work requires discipline:
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:
Here is an example using story points:
Full-Time Run Rate
Idle and Admin
Contract Run Rate
CapEx Story Points
OpEx Story Points
% CapEx vs. OpEx
$12,692.31 over 2 weeks
$39,346.15 over 6 weeks
Your team releases code to production every two weeks.
Your team releases one or more features to production at a planned milestone.
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.
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.
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.
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!
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.
Aha! introduces scenario planning to give product owners the ability to create and compare multiple release approaches based on team capacity and backlog priority.