The Agile Executive

Making Agile Work

Software Capitalization in Atlanta

with 12 comments

Yesterday’s Agile Success Tour event in Atlanta was characterized by quite a strong interest of various participants in software capitalization. While the topic came up in previous success tour events, it was more pronounced in Atlanta. A subtle shift seems to be taking place: from technical aspects of rolling out Agile to business aspects the Agile champion needs to be aware of and prepared to address.

In the course of exploring software capitalization, participants in the Atlanta event brought up related questions about “the business of Agile.” For example:

  • Cost accounting for Agile
  • Return on the Agile investment
  • Agile Portfolio Management
  • Governance of the Agile project/initiative

Some of the participants were quite thoughtful about the dividing line between project-level Agile implementation and Enterprise-level implementation. They grasp that scaling Agile changes the nature of the questions one wrestles with. A few of them are actually considering  top-down approaches to implementing Agile. They do not necessrily subscribe to rolling Agile in a bottom-up manner. They devote quality time to wrestling with Agile scaling issues prior to starting the first Agile project.

I am hesitant to draw general conclusions based on a single event in a particular city. For example, I wonder whether the emphasis on capitalization might be related to the concentration of Supply Chain Management firms in Atlanta.

As the Success Tour “train” continues its journey (next stop: Washington, DC on July 23) we will soon have additional data points. Stay tuned…

Written by israelgat

June 26, 2009 at 8:59 am

12 Responses

Subscribe to comments with RSS.

  1. Israel, Can you provide more detail here? I know software capitalization rules and SOP’s differ for ISVs (FAS 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed), and IT (SOP 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use).

    I also believe data suggests fewer than 30% of ISVs capitalize R&D expenses, but those that do are often aggressive, capitalizing at a high rate so that their expense lines look better than if they did not capitalize these costs.

    What I’m most interested in is their questions on “what changes?” with Agile, and how we can help.

    Richard Leavitt

    June 30, 2009 at 8:40 am

  2. Well, Richard, if you only knew how much scar tissue I got on the subject of software capitalization…

    The fundamental issue is what criteria need to be satisfied in order for software to be capitalized. Much depends on how strict or lenient an auditor is with respect to “working software over comprehensive documentation.” The rule of a thumb I use is that demonstrable software qualifies for capitalization. Practically useful that a rule of a thumb might be, it is not a substitute for broadly accepted criteria.

    Perhaps the thing to do is ask the Agile Alliance to start a working group on the subject. Much of the work could be done by volunteers from the Agile community. However, the group is likely to need access to and cycles of a competent professional auditor.

    It would be a little speculative on my side to assume we will be seeing more companies capitalizing software. However, as so many companies nowadays are looking at various ways to improve their balance sheets, software capitalization is an avenue which is being considered in various places.


    Israel Gat

    June 30, 2009 at 12:08 pm

  3. Israel,

    I agree this can be a huge issue. Actually in my experience, I’ve seen a few issues. First, what type of work can be capitalized? In the past, I’ve capitalized new products and major new features. Maintenance is often excluded. The challenge, however, with Agile teams is making this distinction when Quality ( aka defects ) is baked into the process and backlog. Simply capitalizing stories ( and not defects ) is often not an accurate representation.

    The second issue is getting accurate data. This is both a tooling and a process issue. I remember speaking with a software executive last year that had a multi-million fine from the IRS because they had almost no record of the time they capitalized.

    It’s for this very reason that Rally just released the Beta of a new Time Tracking capability. Our theory is that if developers can easily enter their time while they’re updating their task status and work remaining that it will be inculcated in their daily routine. No developer wants to be bothered with time entry, so it needs to be light and easy.

    The fact is that many Software executives cannot simply ignore governance or “business” issues. We’re spending lots of time figuring how to meet those requirements while balancing the empowerment that Agile teams need to achieve success.


    Todd Olson

    June 30, 2009 at 12:59 pm

  4. Todd, I think you put your finger on an extremely important issue – capitalization in the context of software evolution. Best I know we don’t have
    a broadly accepted definition what “new” is for evolving software.

    This is huge – the cost of evolving (and maintaining) software trumps the cost of “pure” development.


    Israel Gat

    June 30, 2009 at 2:37 pm

  5. […] Capitalization of (Agile) software […]

  6. See for additional coverage of the Atlanta event by Nate Skinner.


    Israel Gat

    July 4, 2009 at 4:43 pm

  7. Click for additional comments by Nate on the Atlanta event.


    Israel Gat

    July 4, 2009 at 4:48 pm

  8. […] a comment » Darren Shipp made an astute observation during the recent Agile Success Tour event in Atlanta: The problem is not transitioning from Waterfall to Agile. The real problem is transitioning from ad […]

  9. […] a comment » Various posts in this blog (click, for example, here, here, and here) brought up noteworthy threads from the Q2 Rally Agile Success Tours events in Santa […]

  10. An employee allocated to a project, but has been idle for 20% of his or her time. Can the salary paid on these idle hours be capitalized under SFAS86.

    Babu Muralidharan

    January 13, 2010 at 3:03 am

    • I don’t know that there is a black or white answer to this question, Babu. Much depends on the flexibility (or lack thereof) of the company’s auditor. A critically important factor is how well the CFO stands up to pressure from the auditor.



      January 13, 2010 at 6:34 pm

  11. Hi Israel,

    Capex vs opex for Agile and iterative dev is a subject dear to my heart (right next to the scar tissue …). Do you know if any progress has been made in the Agile community on this, either formally (eg a working group) or informally (someone coming up with proposals in a public forum)?

    Michael Gentle

    Michael Gentle

    March 10, 2011 at 4:59 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: