Fast and flexible, Agile development is a boon to software organizations. But scaling it is as much a challenge for finance departments as it is for IT.
How can enterprises properly budget for large programs with teams of 1,000 or more people? How can they capitalize Agile development? The answer is by using budgeting tools and a financial model that match Agile’s rapid pace. Instead of relying on one-time, upfront allocations, Agile budgeting is dynamic, constantly readjusting as projects move forward. It’s key to enterprises’ profitability.
Why the Waterfall Model is Anything But Fluid
Despite the fluid images its name conjures, the waterfall model is rigid. So is its budgeting and accounting. Waterfall’s extensive documentation and planning draws on generally accepted accounting practices (GAAP) to capitalize certain phases of software development and expense others.
Phases that create knowledge and capabilities are treated as investments and capitalized, and they become part of a company’s declared assets. Big chunks of R&D, for example, are typically capitalized expenditures (Cap-Ex). Requirements gathering and design are Cap-Ex, also.
Unlike capitalized phases that are depreciated over five years, operational expenses (Op-Ex) appear on financial statements the same year. Op-Ex returns short-term or no residual value. It’s expensed against income statement in the current period. Testing, for example, is typically Op-Ex in software development.
A Smarter Approach to Agile Budgeting
Agile capitalization turns traditional budgeting and accounting on its head. For one thing, Agile development typically moves quickly. A Sprint can complete in two weeks. For another, Agile’s R&D recognizes smaller distributed chunks of capitalized and operational expenses. (For more information on Agile development, read “Software Development in the World of Code Halos.”)
Unless software leaders and finance departments correctly recognize Agile Cap-Ex and Op-Ex, they risk inaccurate development budgets. Incorrectly capitalized expenses can impact organizations’ taxation as well as their brand, reputation and stock price.
Budget Lifecycle for Large-Scale Agile Development
How does Agile budgeting work for large-scale development efforts that consist of, say, 200 teams of 10 people each? How can companies budget for it? How can they account it?
Accurate Agile budgeting requires careful consideration of inter-dependencies and high-level requirements that cascade across development. More important, it requires collaborating with representatives from finance as well as IT.
Fund the portfolio Epic, not the project.
The fundamental shift in Agile budgeting is its focus on Epics rather than on projects. Epics are high-level features that typically take two to three months to deliver.
This change in focus is key – and challenging – for development teams because historically they have leaped into the details of fixed-cycle development. Waterfall projects might budget for as many as 500 requirements. The problem? As projects evolve, changes in product design or market demand typically render several hundred of the requirements to have no value, with no process for re-evaluation.
Agile budgeting sidesteps that dead end by ensuring every requirement prove its worth – and then checking in regularly to make sure it’s still pulling its weight. What’s the value of each Epic? What is its contribution? Agile continually asks tough questions.
Decision makers include the program, portfolio, and Epic leads as well as anyone involved in budget governance. The group defines an operating budget – allocated spend, personnel, and other resources – for each portfolio Epic.
Manage the portfolio backlog.
This key step provides development with a flexibility that wasn’t there in the project days. It takes a deeper dive into the planning that’s established in Step 1 by comparing, sequencing, and prioritizing Epics across all portfolios and available program capacities. It identifies Epics that will add the most value and timelines for their delivery.
Transition to program backlog.
In this final planning step, portfolio Epics are split into program Epics. Features and implementation are scheduled based on program velocity, or how much work programs can deliver. Multiple programs and teams are dedicated to discrete aspects such as managing the backend or mobile features.
Implement program Epic or feature.
This step kicks off development. The work begins to take shape and have form.
Progress – or lack of it – is transparent as development teams gather speedy input on how the investment is tracking within the cadence, or the length of the team's development cycle. Fiduciaries participate in demos to gain assurance on progress being made. All parties stay apprised. There are no surprises.
Fiscal governance and dynamic budgeting.
As each Epic is delivered, its impact on the portfolio budget is reviewed. How much of its allocated funding was used? This dynamic process is key to Agile budgeting. For example, as a result of the outcome of the first portfolio Epic, the PPM team may elect to scrap subsequent Epics.
Too often software development focuses on IT delivery. But without a collaborative approach that properly allocates funding, IT can’t deliver. Agile’s dynamic funding model is essential to its maturity. By vigorously reviewing Agile budgets, enterprise can better prioritize economic value – and bottom line results.
For more insight on Agile development for enterprise teams, please download our white paper, “Large‑Scale Distributed Agile Programs – What is Possible.”