Where The Money Comes From

The more corporate entities I encounter in my career, the more patterns start to emerge. And one set of patterns I've been particular keen to find are those which tend to cause agile adoption to fail. "Agile" itself has clearly moved from the periphery to the mainstream, at least as a buzzword. In today's world no manager wants to admit to a lack of agility after all. But beyond the buzzword is an actual adoption of software development practices which, more often than not in my experience, fail to meet the goal and really end up being the same old status quo with just new names for the meetings.

There are many reasons why agile adoption can fail. It can range from a manager/director/executive/etc. who simply "doesn't get it" to an entire corporate culture which is inherently opposed to it. However, in many cases these failures to adopt seem to stem from some common factors in how the projects themselves are treated at a financial level. In many cases, it seem that the very source of the money for the project is a make-or-break factor for a successful adoption of agile practices.

Now, let me preface this by clarifying that I'm not an accountant. While I'm confident that my own checkbook is balanced and my own finances are handled, I know almost nothing of corporate accounting and budgets and finance at that level. Honestly, it's all white noise to me. I simply have no interest in the subject. But there is one thing I do know. There are two very different kinds of budgets tracked in two very different ways:

• One-time up-front costs
• Periodic ongoing costs

They're tracked separately on whatever spreadsheets are used to track these things. And they're financed very differently throughout corporate accounting structures.

Now consider a software project in any corporate setting. There's an identified business need to make something or enhance something to address an operational concern. And so that project is going to need some money. It's going to need a budget of funds. Where does that budget come from?

• One-time up-front costs

That budget is defined as a fixed figure for one single up-front "purchase" of the project. "For $1.5M we can add these new features to the software. It will take a team of X people Y months to complete." The problem is, that's not really how "agile" approaches things. We don't plan Y months in advance down to every detail. We can't. The very nature of what we're doing has identified that such a plan is inherently incorrect because at the very start of the project is when we know the least about it. But I'm not going to go into the details of what agile is and how it works in this article...

When you consider the structure of an agile software development environment, it's based entirely on iterations of work. Each iteration adjusts its structure based on the successes or failures of the previous iteration. Each iteration is an opportunity for the business to change direction or adjust priorities. Each iteration is an isolated and complete period of development in an ongoing effort. So, from where does it make more sense for the money to come?

• Periodic ongoing costs

When asked "how long will it take to complete" or "what is the whole thing going to cost me" we often try to explain that "agile doesn't work that way." To someone who has a budget in one hand and a calendar in the other, that's not an acceptable answer. We have to go deeper than that. We have to engage at an earlier time, before the budget is defined, and guide the corporate entity not only on how to manage an agile team but even how to finance an agile team.

With a single up-front budget, the iterations are simply burning efforts against that budget. No matter how you slice it up, it's a countdown to "no more money" and a march toward "no more time." Whichever end-game is reached first becomes the deciding factor for the project, regardless of whether the product is ready or not. And, throughout that march, how often did we sell "agility" to the business in the form of changes to scope or priority? How much has the overhead of that cost us against the original budget? Can we still make it before the deadline?

But with on ongoing periodic budget, the control of when anything is finished is entirely in the hands of the business managing the project. It's no longer even a "project" per se, but rather simply a "capacity of work." Each iteration has a capacity, and a certain amount of work can be done in that iteration. As the periodic budget allows, capacity can be increased or decreased. There's really no "end-game" in this scenario, simply the ongoing capacity of work.

It's not that the managers of a failing agile adoption "don't get it." It's that an inaccurate direction was set before we got there. The questions they're asking ("when will it be done" and "how much will it cost") are directly derived from their budgeting concerns, which is what fundamentally drives the business. As an industry we've successfully brought agile into the development domain (even though most adoptions are still unsuccessful, the attempts at least indicate that the desire is there), but we have to continue to adapt to the rest of the corporate structure as well.

We have to not only develop our software with agility, we have to finance our software with agility.