We recently updated the Secure Funding goal diagram, shown below. The change was the addition of the Choose Funding Scope decision point, to recognize that the type of team you’re funding will affect how you fund said team. We have also published details about each decision point and its associated options, including the tradeoffs of each, at the Secure Funding overview page. This is information that we previously had only published in the first Disciplined Agile Delivery book but we’ve decided to start publishing updated versions of this information to the web to make it more accessible to you.
We’ve updated the goal diagram for Secure Funding, an Inception Phase goal. The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.
The New Version of the Goal Diagram
We made the following changes to the diagram:
- We renamed the two process factors to begin with a verb. Funding Strategy is now Choose Funding Strategy and Access Strategy is now Access Funds.
- We renamed the T&M plus performance bonus to Cost plus, the colloquialism for that strategy.
- We added Charge by feature as an option to fund an effort.
The Previous Version of the Goal Diagram
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:
- Yes, this is a valuable activity (33% of responses)
- Yes, this is a waste of time (39% of responses)
- No, but we’re thinking about doing so (2% of responses)
- No, we’ve never considered this (18% of responses)
- I don’t understand what you’re asking (5% of responses, one of which was mine so that I could test the poll)
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:
- It’s a colossal waste of time unless you’re billing a customer by the hour.
- We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
- I think the *most* pointless example was where the managers told us what we should be putting in.
- One day we will move past the “just do it” mentality and have some meaningful conversations and the reasons for what we do.
- In my experience time tracking is a massive waste of time. It’s a poor substitute for management.
- Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
- Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports. And they do not believe that Management can resist the temptation to use task hours as a measure.
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.
Reuse isn’t free. Without funding, either implicit or explicit, meaningful reuse simply doesn’t happen. In short, your approach to funding is a critical success factor for your reuse engineering strategy.
In this blog posting we explore several strategies for funding reuse within your organization. The funding strategies, from most to least desirable, are:
- Funded reuse-engineering team. A team of one or more people in the role of reuse engineer is provided explicit funding to support and enhance the reuse efforts within your IT department.
- Asset-level funding. Funding for a specific reusable asset, such as a security framework or collection of micro services, is explicitly budgeted for. This funding should cover the development, enhancement, and long-term support of the asset.
- Development team-based funding. Funding for the use, development, and enhancement of reusable assets is included in the budget for development teams. Such funding is often accompanied by mandates along the lines of “The team will achieve X% levels of reuse” (although teams are rarely measured against these mandates in practice).
- No explicit funding. With this approach reuse occurs on an ad-hoc basis within delivery teams, often driven by tactical decisions at the team level as opposed to strategic decisions at the organizational level.
- Chargeback funding. Delivery teams are charged for usage of an asset. In some extreme cases development teams are charged to download an asset from the reuse repository, typically because that’s easier to charge them at this point in time over charging for actual usage.
Table 1 compares and contrasts these funding strategies.
Table 1. Comparing the reuse funding strategies.
|Funded reuse engineering team||
|Development team based funding||
|No explicit funding||
Combinations of these strategies can of course be implemented.
- Process Blade: Reuse Engineering (coming soon)
- Disciplined Agile Reuse: Harvesting Potentially Reusable Assets:
- Reuse Engineering: A Goal-Driven Approach
- What can you reuse on agile software teams?
- Reuse Engineering 101
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:
- How you expense cost (and revenue for that matter) is driven first by accounting rules, such as Financial Accounting Standards Board (FASB) in the US, Accounting Standards for Private Enterprises (ASPE) in Canada, and International Financial Reporting Standards (IFRS) IAS 38 in general. The implication is that CapEx/OpEx decisions in part are driven by geography. At the end of this posting is an appendix summarizing these regulations.
- There are a few categories of expense, such as training and education (including coaching related expenses), which automatically fall into the operational expense category regardless of when they occur in the lifecycle.
- Where the appropriate accounting rules provide leeway, for example financial minimums for what to consider for capitalization, your corporate policy will need to guide you. A common problem in established organizations is that some of this guidance was set before agile approaches were adopted and reflect waterfall-style governance.
- How you account for expenses is orthogonal to development paradigm. It doesn’t matter what method the team follows, the actual capitalization rules remain the same. The implication is that you need to determine how to apply these rules effectively for each paradigm, and as you’ll see even by lifecycle.
- This decision, or as we’ll soon show reporting activity, is typically the purview of Finance, not IT. You really shouldn’t have to worry too much about this.
- You must engage the appropriate Finance, IT, and Audit people to ensure that everyone understands the implications of how you’re working and agrees to how you will approach accounting for expenses.
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:
- Conservative: Stakeholder vision milestone. This is the point which most organizations use as their CapEx starting point. As you can see in the appendix, this milestone lines up perfectly with the regulations – you’ve made the decision to go forward with development, you’ve got a technical architecture strategy in place, you have an understanding of what you hope to produce, and so on.
- Aggressive: Project/product team start. Some organizations will choose to start capitalizing at the very beginning of a software development project because they have effectively made the decision to move forward with the effort at that point, they know what the architecture is (due to a good understanding of their existing environment and technical road map), and due to their culture it is highly unlikely that they will cancel the effort.
Of course, there are a few more issues to consider:
- You cancelled the project. If you cancel a project (or release of a product) most organizations will choose to reverse their capitalization decision for any expenses incurred with that project/release.
- You’re prototyping. Prototyping, including time spent on proof-of-concept (PoC) or spikes, is usually considered to be an operational expense because it is a learning activity. This is the case regardless of when in the lifecycle this work occurs.
- Your team follows the continuous delivery lifecycle. Teams following this lifecycle are in the Construction and Transition efforts all the time, so they’re effectively past the Stakeholder Vision milestone (the Conservative point) at all times.
- Your team follows the exploratory/lean start up lifecycle. Teams following this lifecycle are not yet at the point where they’ve made the decision to continue with development, and when they do so the typically kick into one of the other lifecycles anyway. The implication, at least from a conservative point of view, is that these expenses should be operationalized.
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.
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.
- Internal and external costs incurred during the preliminary project stage shall be expensed as they are incurred
- Internal and external costs incurred to develop internal-use computer software during the application development stage shall be capitalized
- Costs to develop or obtain software that allows for access to or conversion of old data by new systems shall also be capitalized
- Training costs are not internal-use software development costs and, if incurred during this stage, shall be expensed as incurred
- Data conversion costs, except as noted above, shall be expensed as incurred
- Internal and external training costs and maintenance costs during the post implementation-operation stage shall be expensed as incurred
International Financial Reporting Standards (IFRS) – IAS 38
You must be able to demonstrate ALL of following BEFORE you can START capitalizing costs:
- Technical feasibility of completing the intangible asset so that it will be available for use or sale
- Its intention to complete the intangible asset and use or sell it
- Its ability to use or sell the intangible asset
- How the intangible asset will generate probable future economic benefits. Among other things, the entity can demonstrate the existence of a market for the output of the intangible asset or the intangible asset itself or, if it is to be used internally, the usefulness of the intangible asset
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:
- Technical feasibility of completing the intangible asset so it will be available for use / sale
- Intention to complete the intangible asset and use / sell it
- Ability to use / sell the intangible asset
- Availability of adequate technical, financial and other resources to complete development and use / sell the intangible asset
- Ability to reliably measure the expenditure related to the intangible asset during development
- How the intangible asset will generate probable future economic benefits