Skip to main content

CapEx or OpEx through a Lean Lens

July 28, 2018
CapEx or OpEx

Does your Finance Department discourage Agile software development because it would all be charged to operational expense?

I have yet to be involved in an Enterprise Agile Transformation wherein we didn’t discuss concerns about how to expense projects that do not have the big upfront phases for documentation and design. The Statement of Position 98-1; Accounting for the Costs of Computer Software Developed or Obtained for Internal Use[1] is based on phase gates not unlike the language used to describe Waterfall software development.   This statement of position was published three years prior to the Manifesto for Agile Software Development.

Scrum does not use phase gates but instead is based on empiricism in which architecture and design emerge over the life of the project. At first glance, it may seem that Agile projects can't fit into the SOP-98 phases because project requirements emerge throughout the effort. Accounting for Capitalization of Agile Labor Costs should be required reading for anyone interested in understanding how Agile projects can be expensed appropriately under SOP 98-1.

Does this mean that there is no way to interpret SOP 98-1 so that we can create significant competitive advantage using Scrum? Pat Reed of the Agile Alliance Agile Accounting Program states that by partnering with the Finance and Technical Accounting people at your organization, it is possible to create accurate, defensible and consistent capitalization solutions for Agile software projects.[2]

If you are experiencing challenges with Agile Capitalization, don't expect the Finance Department to understand the Agile jargon used in your daily work. Start with why these concerns exist in the first place. The original intent of Generally Accepted Accounting Principles (GAAP) was to help companies create accurate, consistent and defensible accounting policies.  These policies do need to be consistent across your organization. Given the complex nature of the Agile Capitalization problem, one might consider using the Scrum framework to work through iterations with Finance professionals, building trust while crafting a collaborative solution for Agile Capitalization.

Finance & Accounting professionals have had twenty plus years to become comfortable with the existing accounting policy, so the most expedient path to success is to assist them in understanding how Agile development using Scrum works.  This will be necessary for them to become comfortable defending an Agile Capitalization approach in your enterprise. Capitalization of Agile projects is a complicated endeavor.  Tolerance levels for Objectivity, Materiality, Conservatism, and Consistency likely vary significantly across firms. Given this variation, each firm should develop its own Agile Capitalization policy.  Trust is essential when building a collaborative solution to Agile Capitalization so that the Finance & Accounting Departments are comfortable defending a solution for which technical team members are not required to know expense rules around capitalization.

The Scrum guide specifies that the Product Owner is responsible for the Product Backlog.  The Product Backlog is an ordered list of what is needed in the product and that it is the single source of requirements for the product.  The Product Backlog will be modified as the product and market in which the product will be used evolves.  In summary, the Product Owner is responsible for telling the Development Team what is required for the product to be successful.  Based on SOP 98-1 this work would be an operational expense.  When it comes to the Development Team, the Scrum guide is also explicit in that the Development Team is self-organizing and no one (not even the Scrum Master) tells the Development Team how to turn Product Backlog items into Increments of potentially releasable functionality.[3]

As part of building this trust, Agilists need to help Accounting / Finance understand the activities in Agile projects that map to the preliminary phase described in Statement of Position 98-1. Like Waterfall projects, Agile efforts also require approval for funding. Business cases and creation of a product backlog of requirements towards a minimum viable product both fit into the preliminary phase. Most if not all the activities related to the Product Owner defining what needs to be built, such as defining Minimum Viable Product and User Story Mapping, would be captured in the preliminary phase as an operational expense.  Resist the temptation to "tailor" Agile practices to fit into Waterfall-based phases.  Do not create Design Sprints, Implementation Sprints, and Test or Hardening Sprints because this approach is not Scrum but merely Waterfall with Scrum labels.

The Development phase captures activities related to how the product (asset) delivers business value. Upon completion of the preliminary phase, all development activities that are related to delivering features can be classified as Capital Expenditures. The Scrum Guide points out that the Development Team handles the “how of what is to be built. These development activities include Scrum Events and the removal of impediments. Because the Product Backlog is a living artifact, it is reasonable to define Product Owner activities related to adding new Product Backlog items as Operational Expense because these activities are new requirements that were identified as the effort was under development.

Post-implementation phase is where production defects and the ongoing maintenance of the product or asset come into play. It is likely that your Finance Department will determine that most of the Post-implementation activities are Operational Expenses.

Because capitalization of Agile projects is a complicated endeavor and tolerance levels for Objectivity, Materiality, Conservatism, and Consistency will vary across firms, the partnership between Agilists and Finance / Technical Accounting can play a major role in advancing your firm’s competitive advantage.



[3] The Scrum Guide™ The Definitive Guide to Scrum:  The Rules of the Game, page 7

What did you think about this post?