What is CapEx vs OpEx?

Capitalization (CapEx) refers to how an organization expends or depreciates its investment costs over an asset’s lifetime. For an asset to be capitalized, whether that is a product or service, it must bring long-term value to the company as a tangible production of value.

For costs outside of capital investments, the term “expenses” is typically used. An “expense” refers to something an organization spends funds on immediately and cannot be depreciated over a longer time period. This is also referred to as operating expenses (OpEx).

In the world of Agile software development, the difference between CapEx and OpEx can significantly impact whether Agile continues to grow and scale as a development method of choice. The reason for this consternation resides in how Agile work is planned and completed.

Unlike waterfall or milestone-driven work, Agile software development does not follow linear processes or gates. As a result, financial planners and accountants often find themselves unsure of how to appropriately attribute Agile software development costs to the correct CapEx or OpEx categories, leading many to expense all development efforts upfront (OpEx), making Agile costs appear very expensive to the company and its investors. Obviously, this impacts future Agile development efforts.

As organizations implement Agile practices more widely in software development, capitalizing their efforts accurately becomes paramount to successful fiscal planning and overall Agile transformations. Additionally, knowing what to capitalize versus what to expense impacts an organization’s tax liabilities and profitability.

When finance inaccurately expenses Agile software development costs, it negatively impacts the business by:

• Under-valuing the profitability of the organization by showing Agile assets as expenses without considering their longer-term value to the company.
• Showing negative implications on taxes, resulting in potential overpayment and undervalue of the company within the year in which the expenses took place.

Without careful analysis of capitalization procedures, Agile software development can potentially appear less profitable and more expensive than other methodologies, resulting in a decrease in headcount and budget, as dollars are used to “pay” for Agile expenses.

But what if finance had a clear-cut way to cost and capitalize Agile efforts? And what if this method was easier for development teams, too? Keep reading to learn more about the benefits of costing Agile, challenges organizations experience, and how to overcome them with enterprise Kanban and portfolio management.

Capitalizing Agile development has many hurdles. Some are due to human nature, and some challenges are because of the way the organization thinks about work in general.

Challenge: Different from traditional accounting practices

While businesses strive to adopt new ways of working, such as Agile, they get stuck in figuring out how to connect traditional operational needs with new, more innovative approaches. A common challenge for those pursuing this latest move to Agile at scale is connecting with finance.

Finance needs to understand costs; it needs to capitalize labor. But traditional accounting rules were built for milestone-driven work (aligned with traditional waterfall development), which is not the way Agile teams deliver.

The traditional way of capitalizing labor is disliked by most Agile teams; time reporting is seen as overhead, as something that doesn’t produce end-user and customer value. Additionally, due to the manual and human nature of the effort, time tracking is only as accurate as the timekeeper, and it is estimated that “people who track their time weekly are 47% accurate. Meanwhile, those who prepare their timesheets less than once per week are only 35% accurate.”

Challenge: Requires buy-in from finance and leadership

For many Agile leaders, financial topics are not typically in their wheelhouse. A common challenge for Agile leaders trying to accelerate Agile at scale is giving finance the data it needs for calculating costs. In a nutshell, finance needs to understand all Agile costs and then capitalize Agile labor appropriately.

This means that finance needs to gain at least a basic understanding of Agile and embrace this completely new way of thinking about capitalizing labor. Meanwhile, leadership needs to be proactive and communicative throughout the shift to enable finance to make the transition to more appropriate costing and capitalization models.

Challenge: Requires change management combined with Agile transformation

One of the key criteria for building a high-performing Agile team is to build stable, persistent teams. Persistent teams could allow an organization to associate a fixed cost to the team (through story point value and / or by averaging the number of hours worked in a particular day or week) and capitalize their work accordingly. This would enable a standardization approach to ensure that financial leaders get a consistent and defensible number.

However, these methods of calculating costs are flawed. Points are relative and cannot accurately reflect effort or complexity of work. And a points system, as well as associating a fixed cost to the team, fails to give leadership any idea of work breakdown. To truly understand who is working on what and when, as well as which features are taking the longest, a different costing method must be used.

The reality is that organizations strive to be fully Agile but likely aren’t all the way there yet. This becomes an additional hurdle in managing Agile team costs.

While Agile rests its laurels on stable teams, that is not the reality of how all Agile teams operate, especially in organizations that are still learning how to scale Agile and are coming from a traditional project management environment. In organizations still highly project-oriented, people move to the work; the work doesn’t move to the people. As a result, it’s likely that only half of the team will stay together for longer than a few program increments.

The truth is that many times Agile team specialists – architects, UX designers, QA members, testers or those tied to software integration details – move in and out of teams more frequently than would be preferable, lending their expertise to teams on an as-needed basis. For organizations still costing projects on a more traditional case by case, one-by-one basis, this level of time management and resource tracking can be cumbersome.

Benefit 1: Automated data capture, auditable costs.

Automating the capture of Agile costs and removing the tax of manual time tracking can solve the problem and provide finance with an auditable way to capitalize Agile software development costs. By utilizing a system that automatically tracks the amount of time developers spend on a story, feature, and corresponding epic, organizations can get a realistic idea of the value delivery of their Agile teams.

Benefit 2: Understand value delivery of teams.

Leveraging intelligent software that can take in the work of disparate Agile teams, apportion their time accordingly, and then roll up the data to a robust portfolio management system, organizations can get a realistic idea of what Agile teams are working on and the value they will deliver.

Benefit 3: Gain an understanding of health across the portfolio with rollup reporting.

This automated rollup reporting is not only great for managing workflows, it can also help organizations gain a better understanding of current state and / or health at the portfolio level, helping to guide funding decisions.

Rollup reporting helps organizations understand what the teams are spending their time on and adjust accordingly based on what’s top priority. Since their time can be apportioned, companies know whether it’s being spent on capitalizable work or expensed work. They can also see the split of work from feature to feature, helping to highlight whether a feature or feature set is becoming a “money pit.”

Benefit 4: Measure ROI of Agile teams, ensure proper CapEx categorization and alignment.

When Agile team actuals (costs and associated work) are rolled up, Agile and finance leaders can better understand the value their Agile teams are contributing to the business and also easily identify which costs are tied to CapEx versus OpEx categories.

This approach to budgeting and funding the value stream or product lines helps ease some of the capitalization and Agile costing burdens. The benefits of Agile costing have a multiplier effect at the Agile Release Train and Value Stream levels.

At these levels, the benefits to costing and capitalization are even more clear. When CapEx / OpEx work is established, the categorization is defined early on, which allows work to align to features that are earmarked as CapEx or OpEx.

Because of this visibility, Agile and finance leaders better understand the true impact their Agile teams have on the bottom line and get a clearer picture of capital expenditures and operating expenses across their Agile development efforts.

Benefit 5: Ensure that Agile teams get the right level of funding and budgeting support for future endeavors.

With Agile costing automated through a software solution or system, organizations find they can capitalize more of their Agile software development work due to increased accuracy. The better information gives teams the data and “proof” required to advocate for the appropriate level of funding and budgeting support for future endeavors.

Benefit 6: Return development capacity back to the business.

With Planview, the simple act of moving a Kanban card obtains, calculates, and rolls up vital information systematically, allowing your organization to easily capture Agile software development capitalization costs and reporting. This automated process removes the need for manual reporting and reconciliation of time sheets, reducing time spent on administrative tasks, increasing time tracking accuracy, and returning development capacity back to the business.