The other day, I met with my new accountant for the first time. (Don’t worry. I won’t name him in case I get something wrong.) It was a routine kickoff meeting; we focused on re-classifying our Income Statement to comply with GAAP . Then he asked me a “typical banker” question: “How are you tracking your software developers’ time?”
I laughed and tried to explain, “No, no, Mr. New Accountant, that’s not how Scrum works. Our company employs Scrum and we focus on macro measurements.” Then I launched into a spiel on the difference between Product Backlog Items (PBIs) and Tasks; Enhanced Burndowns; Velocity ; concepts surrounding team self-organization; and the philosophical difference between time remaining and time estimations. Finally, I enumerated the evils that exist within task-level management, explaining there are times to use micro measurements and times to avoid them at all costs. (For more information, see Michael’s blog on this here ).
After a few minutes, I realized that the GAAP guidelines had not considered how to accommodate alternate methods of project management. In other words, accountants would prefer to use the vernacular of traditional project management to articulate terms and conditions when working with software development organizations — whether they’re ISVs or traditional organizations, such as banks or book stores, developing software.
What I learned was eye-opening. Here’s the deal. In GAAP, there are different rules for how to book software development costs that occur. As defined by the GAAP standards people, who call themselves “The Financial Accounting Standard Board” (FASB) (their ruling number 86) reduces software development to two stages:
(a) The R&D phase; and
(b) The phase that has reached technical feasibility, defined as being established upon completion of a detail program design or, in its absence, completion of a working model.
There’s an incredible disparity between these two classifications and the ramifications of the two differences are major. If you say your product is in an R&D phase and not technologically feasible, then those costs should be expensed. (It will show up as an expense on your Profit and Loss — probably under a bucket labeled “R&D.”) On the other hand, if you classify your software development as “technologically feasible,” then you should capitalize said costs over the lifespan of your product. The capitalized costs don’t show up in your R&D bucket on the expense line, but instead as a long-term depreciating asset on the balance sheet. Consequently, each year you would need to take a percentage of those costs and insert them into your Profit and Loss. (This percentage can generated by dividing the total costs of capitalized expenses over the expected lifespan of your product in years.)
If you’re familiar with Scrum, by now you’re either pulling your hair out or cursing at the screen. The concept of reaching “technical feasibility” utilizing concepts from Scrum and eXtreme Programming could take as little as two to four weeks, whereas the ‘intent’ of FASB 86 could be interpreted as the first few months to years of development within a traditional Waterfall project management paradigm. The idea that a ‘design document’ will first be created and then followed by the team for the next X years is a joke! Long live the sprint planning meeting, the review meeting, and prioritization by the product owner ! To me, both the “R&D” and “technical feasibility” designations seem equally inapplicable in an age of Agile development.
Unlike most of the blogs on the Danube Web site , I won’t say how we’ve decided to deal with this set of interesting guidelines from the FASB. I’m not an accountant or CPA or CFO, so this is just a story, not a practical strategy to resolve this problem. If you are interested in reading more about your choices, please check out this article I found in CFO magazine .
Still, it’s important to note that many financial advisors are completely unfamiliar with Scrum, which means they likely do not understand how it alters traditional product development. In fact, they might even try to convince you that it’s financially risky or fraught with tax consequences. That places a responsibility on the organization to educate its advisors on what Scrum is and what it means to use this framework. This could be achieved through a collaborative meeting between development staff, key management, and your advisors to determine what makes the most sense for the organization’s long-term goals. Or it might be another impediment for a ScrumMaster to address.
Stay tuned because next time we’ll discuss the difference between Major enhancements (however defined by the project management community) and minor enhancements (bug reports) and what the FASB has to say about it!
Laszlo Szalvay
Categories: 
