One of the key aspects of a disciplined agile approach is to be enterprise aware. The fundamental observation is that your team is only one of many in your organization, except in the case of very small organizations, and as a result should act accordingly. This means that what your team does should reflect your organization’s overall business and technical roadmaps, that you should strive to leverage as much of the existing infrastructure as possible, that you should try to enhance the existing infrastructure, and that you should work with other teams appropriately so that your overall efforts are complimentary to one another. This is a straightforward idea conceptually, but in practice acting in an enterprise aware manner can prove more difficult than one would initially think.
Over the years we’ve been asked by several customer organizations to help them to understand how to account for the expense of agile software development. In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations. The details of accounting rules vary between countries, but the fundamentals are common. For public companies capital expenses (CapEx) are preferable because they can boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization’s taxes for that year. Furthermore, in some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature. In order to get properly account for the expenses incurred by software development teams, and potentially to earn R&D tax credits, you need to keep track of the amount of work performed and the type of work performed to develop a given solution. Time tracking doesn’t have to be complex: at one customer developers spend less than five minutes a week capturing such information. The point is that the way that a software developer’s work is accounted for can have a non-trivial impact upon your organization’s financial position. This in turn implies that the need for agile developers to their track time is a fairly simple example of acting in an enterprise aware manner.
So, I thought I’d run a simple test. On LinkedIn’s Agile and Lean Software Development group I ran a simple poll to see what people thought about time tracking. It provided five options to choose from:
The poll results reveal that we have a long way to go when it comes to working in an enterprise aware manner. Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity. When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars. Looking at it from a dollar per minute point of view, it could be the highest value activity many developers perform that week.
The discussion that ensued regarding the poll was truly interesting. Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking. Some comments that stood out for me included:
So what can we make of this? First, it’s clear that delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they’re doing. Second, it’s also clear that management needs to communicate more effectively regarding why they’re asking people to track their time. To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they’re asking for. Third, management needs to govern more effectively. Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result). Fourth, some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and coordination meetings may be preventing people from become enterprise aware because they believe that all of their management needs are being met by these practices. Finally, many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.
Disciplined agilists are enterprise aware. This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization. In the anecdote I provided it was clear that some agile developers believe that an activity such as time tracking is a waste, when that clearly doesn’t have to be the case. Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization. It makes me wonder if some of the agile rhetoric is getting in our way of being more effective as professionals (and, BTW, there are light-weight options for tracking time available to you).
An important financial governance concern in modern enterprises is how to expense costs properly. This of course includes the costs of IT, including the costs associated with agile software development teams. There is more to this of course than just adding up expenses, these expenses need to be categorized appropriately and in some cases can have a measurable impact on your bottom line. In this blog posting we explore how to categorize agile software development costs into either capital expenses (CapEx) or operational expenses (OpEx).
Let’s begin with a few important observations:
Why is This Important?
For publicly traded companies CapEx can potentially boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, OpEX is accounted for in the year that it occurs and thereby reduces net income which in turn reduces your organization’s taxes for that year.
How DAD Helps
As you can see in the appendix most of the rules for when to capitalize boil down to “start capitalizing when you know its real”, something that works well with DAD’s risk-based milestones.
As you can see in the diagram, we’ve identified two potential points where you can start capitalizing software development costs:
Of course, there are a few more issues to consider:
Needless to say, many developers, particularly agile ones, feel that time tracking is a waste. Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much. For CapEx/OpEx purposes you merely need to track broad categories of software development work such as Development, Prototyping, Vacation, and Training/Education. These categories will be determined by the applicable accounting rules and should be kept to a minimum.
Our advice is to keep your time tracking strategy as simple as possible, make it very clear to everyone why it’s important to capture their time accurately, and do not use the data to directly measure individuals. You may find the article Why Time Tracking Might Be the Most Valuable Activity an Agile Developer Performs to be an interesting read. And, as you would expect from Disciplined Agile, we compare and contrast several Strategies for Tracking Time on Agile Teams.
It’s important to note that tracking time simply for CapEx/OpEx reasons is very hard to justify in practice due to the overhead that it injects plus the loss in team morale (nobody likes tracking time). Another option is to simply track the amount of time that the entire team spends in a week and then assign a percentage of that time to each category. This would require a slight amount of effort to track, likely something done by your Team Lead.
The Bottom Line
CAPEX/OPEX decision is fairly straightforward for teams that are following a Disciplined Agile Delivery (DAD) approach. The team simply needs to keep track of important milestone dates (either the Project/Team Start date or the Stakeholder Vision acceptance date) and track their time in a few broad categories as described earlier. If you do that, it’s a simple matter of running a report against your time data.
Appendix: What The Regulations Say
Disclaimer: You must read the actual regulations for yourself, what follows is just a summary and may become out of date overtime as the regulations evolve.
International Financial Reporting Standards (IFRS) – IAS 38
You must be able to demonstrate ALL of following BEFORE you can START capitalizing costs:
Note: It is expected that FASB will recognise IAS 38 in 2016.
Canada – Accounting Standards for Private Enterprises (ASPE)
Based on ASPE, you must be able to demonstrate ALL of following BEFORE you can START capitalizing costs: