Annual Budgeting and Agile IT, Part II: Why Agile Gets Compromised When It Goes Corporate

In the first installment, we had a look at how the CFO is primarily concerned with consistent cash flow so that the business can service long-term financing obligations. As a result, when the CFO is first introduced to Agile, he or she will not be terribly pleased to hear that we’re doing away with predictive planning in favour of continuous reprioritization, even if we allege to be doing it in pursuit of maximizing capital allocation. To the CFO, although IT is a capital investment, it's also a drag on cash flow – cash that the business needs to meet its finance obligations.

In this installment, we’ll take a closer look at this discrepancy. We'll start by looking at what IT does for a business.

Most of IT consists of utility services, the things we need to run the business, such as laptops, virus protection and an office productivity suite. IT utilities become running or operating costs to the business, just like water and electricity: we pay maintenance fees for virus protection and office suite licenses, and buy new laptops when we add a new FTE to the payroll.

Replacing a utility, such as substituting Google Mail for Lotus Notes, can be expressed in investment terms: for the cost of migration, we expect our license fees and maintenance costs to be lower in the future. But replacing utilities is highly invasive to the business, and typically brings with it little capability gain. Firms don't have infinite capital and utility investments tend to offer low payback. Since there's limited upside (we'll squeeze only a little more cost out of the business) and there is significant downside should something go wrong (such as a loss of data or long-term interruption of service), we do these things when business is otherwise calm and we have nothing better to do.

But what about non-utility IT, investments in custom solutions that give us an edge in customer service, makes our supply chain more resilient, or builds our brand strength? Martin Fowler calls this "strategic IT": the investments into technology that gives a business a competitive advantage.

At first glance, these look like they should be treated differently. We don’t always know when an investment opportunity will arise or when we’ll get an idea. We don’t know what that investment will look like until we roll up our sleeves and get on with creating it. From an IT perspective, it would seem a business would be well served by being able to finance a strategic opportunity at the drop of a hat. This also seems like precisely where the Agile would appear to shine.

Unfortunately, it isn’t as simple as that.

Software development is the act of converting capital into intangible assets by way of human effort. Let’s look at what it means to finance IT effort.

Human effort is a payroll cost, which is a running cost to the business. If that human effort comes from our FTEs or direct contractors, it's our cash covering our payroll. If that human effort comes from a firm we've contracted with, it’s our cash covering somebody else’s payroll. As CFO, you don't miss your own payroll, and it doesn't do you any good if you cause a key supplier to miss one of theirs.

Payroll, like debt servicing, requires consistency. If software development is going to be a core capability, the CFO needs to know how big that capability is going to be and what impact it's going to have on cash flow. The CFO will also tell us if we’re building a captive IT organization that we simply can’t afford.

In strategic IT, meeting payroll isn’t just a matter of people and salaries. We have multiple funding buckets to be concerned with.In many businesses, software is treated as an asset. Even though it's intangible, software shares many of the same properties as tangible assets such as trucks or machinery: we can't operate the business without it, it tends to be expensive, we get multiple years' use out of it, we might make improvements to it, and it requires ongoing service and maintenance.

When we treat software investments as assets, we capitalize them. Software is capitalized over a 3 year period. Since we're going to get multiple years of use out of something, it's acceptable to distribute the cost of acquiring it over multiple periods. This reduces the volatility of the income statement: as they tend to be expensive, taking the full cost of acquisition in period 1 would excessively depress earnings, while having already reported the cost would mean earnings in periods 2 and 3 would be that much higher. This means capitalization has income statement impact for future periods - something the CFO is going to be particularly interested in.

Before we go any further, let's be clear about the accounting going on. For income statement and balance sheet purposes, we're going to capitalize the cost of developing software. This is a long-term treatment of software assets. But we still have payroll costs to meet, which impacts our cash flow. This is a short-term treatment of the effort used to develop those software assets.

We saw a lot of this in 2009: record cash balances allowed companies to cover costs, while moving more spending to capex contributed to strong earnings. Depending on a firm's experience of the financial crisis, this either deferred difficult decisions such as layoffs until cash became too tight, or, if they rebounded relatively quickly, it allowed them to emerge a much stronger competitor because they were able to retain experienced people throughout the crisis.

In practice, though, this two-speed accounting introduces a bit of friction. A CIO can’t simply choose a finance bucket out of which they’ll pay for salaries. Payroll allocated from a capital account is incurred against a specific asset in the general ledger, something the CFO must authorize. The rules governing capital expenditure are pretty strict. Labor costs can only be capitalized if they are demonstrably performed in the fulfillment of the expected characteristics of the asset itself. Labor costs incurred in R&D and administrative work always go to operating expense. So must any labor costs associated with defining what the asset is to be in the first place, work typically associated with early stage analysis. The devil is in the details, and in large corporate IT organizations, knowing that we're tracking the right effort to the right bucket gets cumbersome very quickly. We must be able to show that we're consistent and in compliance with these accounting guidelines. If we can't satisfy the auditors, we'll face a financial restatement. That's career limiting.

Where it gets really complicated is when there is a volatility in the IT portfolio. If the business pulls the plug on an in-flight capex project, we have to figure out how we're going to cover payroll of the people who were working on that project. We either have to have another capital investment ready for them to work on, we have to have sufficient unallocated opex to cover their payroll costs, or we have to lay them off. In finance terms, this is equivalent to a liquidity squeeze (inaccessible budget or insufficient budget) that can cause a solvency crisis (loss of skills and capability).

This brings us back to the question of how we finance "human effort". Human effort isn’t as liquid as capital. We steadily bleed cash from the business to meet payroll costs of the effort we’re buying, with only an occasional delivery of a software asset that enters use and has an impact on our business. The effort that we’re financing hasn't the financial properties of the capital we pour into it nor of the asset that it produces.

When we choose to fund salaries out of capex, we are beholden to that effort yielding a result. If that's going to happen, the effort has to be reasonably framed (estimates are valid, scope well defined, etc.) and that the business environment has to be static (the business will still want the intangible asset we’re delivering). Capex spending further binds IT to the financing structure of the business. The annual budgeting cycle that still governs companies sets an expectation that operations, IT included, will perform consistently with a big, up-front plan.

This is a contributing factor to why we see CIOs resorting to terms such as “control” and “predictable” rather than “fail fast” when explaining Agile to the CFO: it's a capitulation to the over-riding realities that drive a company. Being "predictable" reinforces the operational objective to produce consistent cash flow for finance; failing fast is a threat to it. It comes as no surprise that by the time Agile reaches the most senior levels of the business, it's been co-opted into the language of industrial management, just substitute "Scrum" and "burn-down charts" for "Waterfall" with "Gantt charts". Agile is rolled-out as a means of "guaranteeing predictability", or greater efficiency, not as a means of making better use of capital, or being more resilient to unforeseen events.

It's worth drawing a comparison between captive IT that engages in application development, and technology firms. Tech firms typically have highly volatile earnings and cash flow, which means they tend not to rely on debt financing. It's no coincidence that tech firms tend to be hotbeds of innovation, while captive IT departments in large corporates are not. Large tech firms are typically debt free, while tech startups tend to go one step further by trading equity for salary. Because tech firms aren't beholden to consistency, let alone predictability, independent tech firms have the luxury to pursue discovery. Discovery tends not to come from the mundane, and is amplified by creative freedom.

Which brings us back to the fundamental disconnect between Agile and the CFO. In corporate IT, the CFO isn't trying to solve a "make better use of capital" problem in the business. He or she is trying to solve a "consistent cash flow from operations to service our capital obligations" problem. When Agile goes corporate, it is subservient to, and most often compromised by, that latter problem.

In the final installment of this series, we’ll look at what we can do to make Agile IT appealing to the CFO, without compromising the core characteristics of Agile.