Disciplined Agile

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).

Some Basics

Let’s begin with a few important observations:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

Time Tracking

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.

US FASB 

• 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

Related Reading

• The Secure Funding process goal
• The Finance process blade

In this posting we briefly explore why both you and your organization should consider adopting a Disciplined DevOps mindset.  For yourself as an individual there are several interesting benefits.  First, you become more productive as an IT professional, increasing your chance at promotion and making you more attractive in the marketplace.  Second, you are in a position where you can focus on interesting, value-added work, which should lead to greater job satisfaction for you.  Third, much of the dysfunctional politics exhibited in traditional IT  organizations is effectively squeezed out as you move to a Disciplined DevOps mindset, making your work environment a more enjoyable place to be.

There are many reasons why your organization should consider adopting a Disciplined DevOps mindset.  The following table summarizes the potential benefits and how they are achieved:

As always, we welcome any feedback that you may have.

This blog posting has been replaced by Enterprise Architecture Strategies for DevOps.

In the Disciplined Agile (DA) toolkit data management is a Run (operational) activity that focuses on the execution of data-oriented architectures, policies, and processes. Note that the long-term planning efforts around data-oriented aspects of your organization are part of your Enterprise Architecture efforts. Similarly, development of the data-oriented aspects of your organizational eco-system is addressed by solution delivery teams.

Because data management is an important aspect of your Run endeavors it will be affected by your Disciplined DevOps strategy. Our experience is that in addition to the general DevOps strategies describe previously, there are several data management strategies that support DevOps:

• Data and information guidelines. A straightforward way to promote greater consistency in the development and application of data and information sources is to have common guidance that teams will adopt and then follow. This guidance, including both standard policies and guidelines, will need to be defined, supported, and evolved over time in a collaborative and open manner.
• Quality data sources. Your production data sources, including files, databases, and data feeds, should be high quality assets that are easy to work with. When it comes to data sources of record it is particularly important for them to be of high quality so that they are easy to work with and evolve. Unfortunately this is often little more than fanciful thinking in many organizations. With a Disciplined DevOps mindset teams realize that they should be very careful about increasing the technical debt within their data sources, and more importantly invest in the effort to pay down any technical debt that they find.
• IT intelligence.  IT intelligence is the creation, support, evolution, and operation of  data warehouse (DW)/business intelligence (BI) solutions that support the management and governance of your IT efforts. From a Disciplined DevOps perspective this there are two important aspects of IT intelligence: development intelligence that provides insight into how delivery teams are working and operational intelligence that provides insight into what occurs in production. The automated team dashboards provided by many development platforms are a simple form of development intelligence, a more sophisticated (and useful) strategy is to combine information from various development tools to display it in an integrated dashboard for the team, and more sophisticated yet is to roll up/combine information from different delivery teams into a portfolio management dashboard. Similarly your operations team may have individual dashboards for each solution, they may combine information being generated by individual solutions into an integrated dashboard, and better yet share that information for an IT portfolio management view.

In the next blog posting in this series we will explore DevOps strategies pertaining to enterprise architecture.

In addition to the general release management strategies described previously, the general DevOps strategies, and the construction-focused DevOps strategies (including continuous deployment) there are several other release management strategies that support DevOps:

• Integrated deployment planning.  From the point of view of development teams, deployment planning has always required interaction with an organization’s operations and release management staff; in some cases, via liaison specialists within operations often called release engineers. When you adopt a Disciplined DevOps mindset, you quickly realize the need to take a cross-team approach to deployment planning due to the need for operations staff to work with all of your development teams. This isn’t news to operations staff, but it can be a surprise to development teams accustomed to working in their own, siloed environments (luckily this strategy is built into DAD’s Move Closer to a Deployable Release process goal). If your team is not doing this already, you will need to start vying for release slots in the overall organizational deployment schedule.
• Standard development and testing environments based on production. Development teams know that the greater the consistency between their development, testing, and production environments the easier it is to test and deploy. In multi-team environments the implication is that this will result in defacto standardization of many aspects of your environments. Developers may choose different development tools, but aspects of the infrastructure such as operating systems, application servers, middleware, databases and so on will become consistent over time to streamline the overall release process.
• Release service streams. A key tenant of DAD is that every team is unique, and an implication of that is that some teams will need more help than others. Teams will produce different levels of quality, they will have different amounts of automation, they will have different release cadences, and so on. As a result your release management strategy needs to be flexible enough to address these different situations. One way to do so is to offer different server streams, or service levels as it were, to solution delivery teams. For example, you may have a basic release management service stream where release management engineers actively help delivery teams to deploy their solutions into production and even help them to start automating some of their processes. At the other end of the spectrum you may have a continuous delivery service stream for delivery teams that have fully automated their testing and deployment processes and that can be trusted to successfully deploy on their own. And of course you could have several other service streams between those two extremes. The advantage of this approach is that it is very flexible albeit at the cost of slightly greater scheduling complexity.
• Release blackout periods. Some organizations have periods of time where they choose not to release new functionality into production unless it is absolutely critical. These blackout periods typically occur during high-volumes of business transactions. For example, many North American retail companies will have blackout periods between mid-November and early January for the holiday sales seasons. Many organizations will have blackout periods near the end of their fiscal years to enable them to focus on the process required to close out the year.
• Shared practices. Although this is really a process improvement issue, it’s worthwhile to point out that whoever is involved with release management should actively strive to share effective practices between teams. Sharing learnings across teams is an important aspect of enterprise awareness.

In the next blog posting in this series we will explore data management strategies that support a DevOps mindset.