Fund Your Transformation through Increased Agile Capitalization

With the severe impact COVID-19 has had on most businesses during the last several months, many organizations are putting their key transformation and improvement initiatives on hold.  This may be due to uncertainty of the future and the direction of the company, it could be due to changing priorities, but most commonly, it’s due to the financial impact many industries have suffered in 2020. Most organizations want to continue or embark on their transformation efforts but are finding it difficult to do so during this time. If you’re feeling the pain from these circumstances or simply need to free up some OpEx flexibility, allow me to introduce an approach that could help fund some of your transformation work or other key improvement initiatives that will help prepare for and lead future disruption.

First, a little context. Almost all organizations are now technology companies no matter what products or services they provide and most have adopted Agile methods as a means to rapidly deliver products that delight customers. While most Product and Technology leaders see Agile as a key component to their future business success, many finance leaders struggle with Agile due to the uncertain accounting impacts and unfamiliar capitalization rules. Some feel they will be forced to expense all Agile development costs due its iterative nature and take a significant hit in their financial reporting. It’s clear that without an aligned approach for how Agile development work is costed and capitalized, organizations will face an uphill battle when securing budget and people for their Agile teams or projects.

So the real question is, should Agile development work be capitalized or expensed?  While it’s true that all organizations should develop a strategy based on their unique circumstances, a couple of key concepts should be understood.  First, that long-lived assets (at least 2 or more years) can be capitalized according to GAAP guiding principles regardless of which delivery mechanism by which they were created. And second, costs incurred through research, assessing feasibility, knowledge transfer and support of assets should be expensed.  Because most of the work involved in an Agile delivery sprint is related to the building or enhancement of valuable long-lived assets, according to GAAP guidelines, those costs can be capitalized if the organization chooses to do so.

Benefits of Agile Capitalization

So why would an organization choose to capitalize versus expense when the rules aren’t as clear cut? Let’s look at several reasons why it might be of benefit:

• Increased OpEx flexibility: Capitalizing Agile development provides a direct impact to the bottom line as organizations are able to amortize their assets over a period of years rather than take the hit in the year an asset was built. This can potentially free up significant OpEx capacity for other initiatives such as Digital and Agility transformation work.  For large organizations currently capitalizing less than 50% of their eligible Agile work, this could be an opportunity in the tens of millions as illustrated in Figure 1 below.

  Figure 1

• Increased accuracy in Financial Reporting: Capitalizing Agile delivery efforts will show a more accurate representation of how your labor is utilized, whether towards asset creation or other activities. Additionally, since asset revenues typically flow much more in years following its creation, expensing all costs to deliver the asset in the year it was delivered could show significant variation in year-to-year financials, prevent utilizing heavy cost tax benefits in high revenue years and gives the false impression the organization is stuck in a “Run the business” mode rather than always innovating, as shown in Figure 2 below.

  Figure 2

• Agile Capitalization Incentivizes Consistent Core Agile Practices: Due to the nature of reporting labor costs for eligible capitalization work, it behooves an organization to improve and standardize their core Agile practices around Stable Cross-Functional Teams, Consolidated Team Backlogs, Consistent Team-led Estimation, Planning based on Priority and Team Capacity, Healthy Inspect and Adapt Practices and Clear Delivery Metrics.
• More Streamlined Administrative Overhead: Traditional capitalization typically requires manual time tracking, which can be overwhelming for employees, often limits innovation in creative technology development and is only 60-70% accurate at best. Agile capitalization focuses on team capacities and can be tracked utilizing points or story tracking, which are much easier to track and should already be part of most agile team’s natural process.

These and other potential benefits should at least invoke the conversation in your organization as to whether Agile initiatives should be capitalized or whether it makes sense to increase the current capitalization rate. However, it is critical that we understand what Agile work can and cannot be capitalized under GAAP rules. Let’s make this very clear; any work that contributes to the foundational setup, development, testing and fixing any new functionality that is part of a long-lived asset or work that helps the team’s process in support of these activities such as backlog/requirements refinement and team ceremonies, can be capitalized.  Any activities that involve the discovery, planning, funding, staffing, feasibility and maintenance & support of new assets should be expensed as shown in Figure 3 below.

Figure 3

This means that most work that is done within an Agile team’s sprint or Kanban process can be capitalized with the exception of work items such as spikes or specific research stories, knowledge transfer or fixing defects from previously released work done in the past.  However, we do recommend specifically categorizing the different types of work in your work management system as I’ll describe in our next section.

8 High-Level Steps for a Pragmatic Agile Capitalization Proof of Concept

If you are intrigued by the concept of increasing your Agile capitalization levels, it is typically wise to start with a proof of concept (PoC) to test and validate how it can be operationalized within your organization.  We offer you a proven 8-step approach for running your PoC and ensuring you are ready to move ahead.

1. Engage the Right Stakeholders to Design the Solution: It is critical to involve the right stakeholders to ensure all impacted organizations are represented and have a voice. This capitalization impacts the bottom-line, this will be a topic these stakeholders will not want to be left out of. These stakeholders should include Finance & Accounting, Product Management, HR, Controller Group, Audi and Engineering among others. See Figure 4 below for a more comprehensive list as well as topics they should align on.

Figure 4

2 Align on the Goal: Ensure that all stakeholders are aligned as to what outcomes and results you are hoping to gain through Agile capitalization and what problems or challenges this will help solve for the organization

3. Agree to a PoC, Validate & Scale Approach: Ensure that all stakeholders agree on the notion of a PoC rather than jumping in too wide. It takes a little time for everyone to feel comfortable with the process and to iron out the kinks of an initiative like this.

4. Align on Test Requirements before Jumping In: It’s important to ensure all parties are clear on what we are testing hoping to prove/validate with the PoC approach. It’s best to ensure everyone understands what data is needed so they can make the best decisions for full implementation.

5. Review Preliminary CapEx vs OpEx Criteria: Stakeholders should have a clear understanding of the organization’s current criteria for capital expenses versus operating expenses and make the effort to build out a CapEx vs OpEx decision tree based on the decisions and goals around Agile capitalization. This information should then be shared to any leaders and teams that are impacted.

6. Align on the Tracking Method to Test: This is where your teams will feel the biggest impact so it’s wise to align on a method that is lightweight and will give you the data needed for your capitalization approach. There are three commonly utilized methods for tracking, all with some pros and cons. These are outlined in Figure 5 below:

7. Agree to PoC Scope, Timeline and Target Outcomes: Once a tracking mechanism is decided upon, stakeholders will then need to determine the full breadth of scope for the PoC, the implementation timeline and the specific outcomes we’re hoping to validate through the PoC itself. Always take an inspect and adapt approach to the PoC.

8. Train and Support PoC Participants: The final step is to ensure all participants are aware of the PoC goals and outcomes, train them on the mechanics of the rollout and support them as they have questions, experience challenges or have suggestions. Be open to feedback and recommendations from those participating in the PoC as they are directly impacted and will be a representation of the broader organization.

If you are interested in assessing your current state of Agile capitalization to determine how much opportunity scope you may have, we have recently launched a Agile Capitalization Discovery radar that will give you this necessary data. As shown in Figure 6 below, you can see the key dimensions of Agile Adoption, Opportunity Scope, Data & Systems Maturity and Stakeholder Alignment. You can utilize the radar with your internal stakeholder group to get a full view of your Agile Capitalization readiness or you can try out the Kiosk version of the radar by clicking Start Assessment.

Hopefully, this has given you a better understanding of what Agile Capitalization is, how you may be able to fund your transformation initiatives with increased capitalization and how it could be implemented with a PoC approach. For additional information, you may also be interested in our recent webinar on Agile Capitalization.

By Bryan Tew, Enterprise Business Agility Strategist