Take the 2-minute tour ×

When it comes to financial topics, I'm admittedly not well versed. I'm trying to lead my organization in our software development effort using a Scrum based development life-cycle. I am often discouraged when trying to coach executive leadership due to their belief that Scrum and Agile don't play well with their finanacial objectives. The other day I was challenged to show how my software developers could capitalize %60 of their work hours.

I've found a few articles on the web ( http://itprojectfinancials.com/insights/2011/06/05/capitalizing-software-development-costs-from-sdcl-to-agile/ ), but haven't come up with any great arguments.

I'm looking for advice or examples of organizations that capitalize software costs effectively in an Agile development environment.

This article sums up the issue pretty well, but offers no advise http://blogs.collab.net/agile/2007/12/20/the-scrum-gaap/

share|improve this question

migrated from stackoverflow.com Jan 24 '12 at 9:50

This question came from our site for professional and enthusiast programmers.

damn suits...... –  hvgotcodes Jan 24 '12 at 1:20
This blog post might be relevant, but what exactly are your superiors asking for? They want you to prove that every staff member will be working on a project (and not on overhead time/money) for at least 60% of their time every week? –  Thomas Owens Jan 24 '12 at 10:30
One of the biggest issues I have is that, with waterfall, design and development are distinct. So the argument is that we can keep developers focused on development (capitalized) and have designers and architects focused on design. It gets cloudier when everyone on the team participates in the whole life-cycle of activities. I can easily make the business value and quality arguments for Scrum, but... –  garrmark Jan 24 '12 at 14:24
This seems off topic to me. Not to mention that this really depends on the country you're in. –  Dave Hillier Jan 5 at 15:21

4 Answers 4

This shouldn't be your problem.

Capitalisation of costs is your company CFO and/or accountant's problem. The rules vary in different jurisdictions. The accounting guys are the experts and should be capitalising costs according to the relevant accounting rules.

At most, they may need to ask you for some supporting information (e.g. of the 5,000 developer hours worked this quarter, can you estimate what % was on new software development or enhancement of existing software assets?). But it's up to them to ask you the right question.

If you are doing mostly new software development in a product that your company sells or intends to sell (i.e. the product counts as an intangible asset which returns future economic benefits) then it's perfectly possible to capitalise 100% of development costs. Also some countries have special incentives for R&D investment which is possible your software development work may qualify for.

The software development methodology you use is irrelevant, the only thing that is likely to matter is having some way of categorising which costs were spent on capitalizable projects or assets. But the same problem applies to waterfall development!

But for goodness sake, let the accountants sort this all out. You don't expect the CFO to write code, do you?

share|improve this answer
I agree with your points, but at some level, it is his problem. He's proposing a process improvement effort, and the business management side of the organization wants to ensure that time spent on (at least what we call where I work) overhead (any work not directly supporting a program or technical project) is minimized. I think they might be asking the wrong questions, but it is a valid concern (from their perspective) to maximize the time spent on billable or non-overhead hours. –  Thomas Owens Jan 24 '12 at 11:53
At the end of the day, if you don't get funding you dont get work! That's your problem! Managing money for organization is everyone's problem in the company, and OP's point is anyway to help organization in someway not to dodge Accountants! –  Dipan Mehta Jan 24 '12 at 11:57
BTW: There is a difference between CFO, and Accountants. Part of the irony amongst programmers is that they fail to recognize business need from process jargon and feel frustrated! –  Dipan Mehta Jan 24 '12 at 11:58
One of the ways that the financial aspect currently hinders our agile adoption follows. I get push-back when I say that developers (as well as other team members) should be involved in backlog grooming sessions. Since that activity is overhead, they would like to reduce developers involvement. My argument is that a little bit of upfront involvement goes a long way. –  garrmark Jan 24 '12 at 14:45

I read the link you posted. It is bare basic and riddled with assumptions! If you have to defend it really, hard luck!

Nevertheless, i would say, convincing CFO shouldn't be hard (once you know what matters).

The point is, no CFO is really worried about the money being spent (if there is a due justification) as much as he is worried that money gets wasted because at the end project fails. (The article you posted simply ignores some simple real life situations); If you really want to promote Agile - never promote it to say it will reduce cost. The point primarily is that

  1. it reduces risk : it will ensure you won't have to write off the whole stuff! If at all you do have to - you will ensure that with Agile/Scrum you would have realized this much earlier than other methods.

  2. it reduces your risk on waiting to get to market (and start revenue) much earlier than waiting the whole log finished.

  3. it reduces your risk on building the wrong project!

This is true with any iterative method and not just Agile/Scrum. What you really need to show is not that Agile is better done; but how horrible things are when projects fail. (I guess that's where explaining CFO is even better than IT heads because they start defending stuff straight away!).

In general, if organization (and specially leaders) is attuned to such philosophies (like waterfall), it is probably a bad idea to sell-by-promise. It is better to demonstrate-by-doing it. Start out small where you have a comfortable control. And probably the first stab i would do is to question - why start with so many features? Let's divide them into 10 releases! Next, who stops you from meeting customers? Step-by-step, start adhering some parts of the Agile without making explicitly announced rituals. Once, you go successful, people will see the point as to what Agile will bring on board.

When you make specific recommendations, (rather than philosophy) people tend to listen a lot better.

share|improve this answer
I like your comments and feel that we've been doing a good job of selling these points in our organization. –  garrmark Jan 24 '12 at 14:49
It sounds to me not like the CFO is worried about the cost of a project so much as billing developer time. Very likely this is a consulting-type shop, doing projects for others and billing time. In that case, I'd suggest finding ways scrum helps keep developers busy developing. –  David Thornley Jan 27 '12 at 18:59

You're leaving out a lot of information, and as a result I'm going to guess you're not a consulting company; since in that case, in my opinion all hours that all billable are able to be capitalized.

Okay, so honestly, what the CFO wants to hear is a good argument for why a huge percent of the hours are non-R&D hours -- and as far as I'm able to tell ruling number 86 by the FASB is the only rule that matters; though I'd highly recommend reading the real document, and not the summary.

To my knowledge the only hours that would always be categorized as R&D in Scrum are during spikes, all other hours 'might' be considered non-R&D hours in my opinion; meaning Scrum is about only doing what's feasible.

Further, if you read the accounting guidelines, they're not defining feasible by market feasibility, but the belief the effort is feasible after a full iteration of work is done. Well one iteration might easily be claimed to be one sprint, which includes "For purposes of this Statement, the technological feasibility of a computer software product is established when the enterprise has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications including functions, features, and technical performance requirements." After that everything is able to be capitalized, unless you believe some part of the project 'can [not] be produced'.

(Lastly, I'm not a CPA, and likely no one else here is either - and even if they were, taking advice of the internet for accounting practices is what it is. If you're not happy with any of the answers, then honestly I'd suggest the company hire a 3rd party, make them accountable for their opinion, and be done with it.)

share|improve this answer
up vote 0 down vote accepted

After having an interesting twitter conversation with Berry Hawkins ( http://twitter.theinfo.org/162880048838352896#id162964857744932864 ) I think I have my answer.

The problem is that I was still thinking that I needed to have my developers account for their time spent designing software as an expense.

The solution is to look at whether the activity is before of after the product or feature is considered feasible. Any activity, regardless of whether it's design, development, or test can be capitalized as long as it's past the research stage.

I've written up some new guidelines and have them in to my CFO for review (fingers crossed). The real test will be the auditors, but I think getting the CFO on board is the first step. Thanks for all your comments.

share|improve this answer
I'm just a software engineer and since my company picked up a tab for an MBA degree, I decided to get one just for the hack of it. Even I could have told you these capitalization rules, so if this is something your CFO needs to have presented to him, it's possible your company is in some serious trouble. –  DXM Jan 31 '12 at 5:02

Your Answer


