CapEx 101: Resolving the Agile vs. Waterfall Conflict With Hybrid Methodology

The impasse between Agile and Waterfall processes has persisted in project management discourse for decades. Software development teams thrive in Agile environments, but a lack of management support is one of the major obstacles to Agile transformation. A project manager working in the software industry for any length of time has probably encountered a C-suite that wants them to “do Waterfall.” But what exactly does that mean in practice?

For years, studies have shown a positive relationship between the use of Agile frameworks and project success, and it may be tempting for a project manager to believe they just need to sell their corporate officers on Agile’s results. But it’s equally important to understand what upper management likes about the Waterfall methodology. If you understand the financial safeguards that Waterfall affords the C-suite, you can craft a hybrid framework that will bridge the gap between Agile practices and enterprise Waterfall once and for all. The beginning of that understanding lies in Waterfall’s mostly untold origin story.

The Murky Origins of Waterfall Methodology

Most people in organizational management associate the term “Waterfall” with the chart below, which comes from “Managing the Development of Large Software Systems,” an influential academic paper written by Winston W. Royce, PhD, in 1970. Royce’s illustration is widely credited as the first expression of Waterfall development.

The crediting of Waterfall development to Royce’s research is one of the strange ironies of the software industry. In his paper, Royce never uses the word “waterfall” or advocates it as an effective system; he actually presents what would come to be known as Waterfall as a cautionary tale—an example of a process that is “risky and invites failure” because it does not account for the necessary iteration needed among software development stages.

Royce was not alone: 18 years later, Barry W. Boehm, PhD (who would soon become director of DARPA), used a very similar illustration, again as an example of a problematic software development life cycle, and proposed iterative development as a favorable alternative. In 1996, almost the entire software industry endorsed an iterative development cycle called the Rational Unified Process (RUP), which was itself a synthesis of best practices universally recognized by software engineers.

This raises a big question: Why would anyone in management push back against the use of Agile over Waterfall, a framework that since its inception has been seen by industry experts and professionals to be at odds with efficient development practices?

OpEx vs. CapEx: The Financial Case for Waterfall

The reason Waterfall remains in favor requires a little knowledge about a business function that development teams seldom think about: accounting.

In double-entry accounting, there are two kinds of expenses: operational expenses and capital expenses (also commonly referred to as OpEx and CapEx). Any expense lowers the net profits of a company, but an operational expense—such as rent, payroll, or insurance—lowers it more. The money is spent, and is therefore no longer on the books. A capital expense—such as real estate, factory equipment, or office furniture—lowers profits less because of an accounting technique called depreciation, which distributes the expense over several years. Also, once an asset has been purchased, it is considered part of the company’s net worth.

Between 2000 and 2002—even as the Agile Manifesto was being developed—the corporate world was rocked by a pair of major accounting scandals, starting with the US energy company Enron. Put simply, Enron (with the alleged complicity of accounting firm Arthur Andersen) concealed major losses from investors by intentionally mismanaging operational expenses and capital expenses. This was part of a larger scheme to fraudulently inflate its profits, and therefore boost its stock market value, by billions of dollars.

Shortly thereafter, a similar scandal occurred at US telecommunications company WorldCom. WorldCom also hid losses by purposefully miscategorizing operational expenses as capital expenses, and the 2002 session of Congress reacted by passing the Sarbanes-Oxley Act. Included in this bill’s provisions were new rules that made company officers, such as the CEO and CFO, personally liable for shareholder losses that occurred because of a lack of due diligence.

When it comes to software development, CapEx versus OpEx is an especially complex issue: CapEx looks good on a balance sheet, allowing companies to report a better operating income and borrow larger amounts.The downside, however, is that capitalization criteria have evolved and require documentation, reviews, and approvals—all of which can greatly hinder the software development process.

This is where project management plays a central role. In the wake of this legislation, CFOs needed a safety mechanism that they could point to: a management style that could prove they had met the requirements of the Sarbanes-Oxley Act. The Project Management Institute had a solution: the phase-gate process (also known as stage-gate). This Waterfall technique uses a series of “gates”—pauses where executive approval would be needed for development to advance. By defining a stage that contained only CapEx-eligible activity, and isolating it from all other stages, CFOs could prove that they had exercised due diligence when listing an expenditure as a capital expense.

Fast-forward to the present day, and phase-gate management has been the de facto standard for development projects at public companies for 20 years—Stage-Gate International estimates that 80% of the Fortune 1000 uses some variation of this framework. For an Agile developer or project manager, this may seem baffling. Doesn’t your CFO know the benefits of Agile? They may or may not, but either way, the most important thing for a project manager to remember is: They don’t care.

When the CFO wants you to “do Waterfall,” it’s not based on a belief that Waterfall is the most effective way to deliver software. It rarely matters to them if programmers use RUP, Scrum, XP, Crystal, FDD, DSDM, Kanban boards, or any other development technique or management framework; what they care about is capitalizing the project without violating the terms of the Sarbanes-Oxley Act.

The good news is that everything you need to do to assure the CFO that the project will pass an audit takes place outside of the actual development process. If you can assure the C-suite that their needs will be met, they should be amenable to a hybrid methodology in which financial concerns are handled via Waterfall in the planning stage and development is done in an Agile framework:

Navigating the Falls

If a project manager understands what their CFO wants and can assure them of the operational oversight provided by a phase-gate framework, there’s no reason to use Waterfall over Agile in development. Just approach the requirements of phase-gate management with the understanding that its purpose is financial and legal and does not have to impact your team’s development work. Here’s how to get started:

Treat Budgeting as Iterative … Until It Isn’t

Every year, the corporate budget allocates a fixed amount to capital expenditures. One small piece of that is allocated to software development projects, and business leaders negotiate for the biggest slice possible for their projects. This negotiation process usually goes on for the first two or three months of the fiscal year.

Negotiation is extremely iterative, so project budgets fluctuate constantly throughout this process. Empower your business sponsor by providing them with adjustable estimates. The goal here is to establish a budget envelope, so broad options for multiple contingencies will be extremely helpful. For example, alongside a baseline estimate, you might provide a cheaper option that would be feasible if cost-saving conditions are met, like doing data migration via manual entry, or a more expensive option if extra features are included, like a mobile app. This will help your business sponsor adjust their budget request as treasury committee negotiations get underway.

These estimates need to be provided ahead of budget negotiations, because once the treasury committee approves the projects for the year, there is no going back. In the phase-gate system, gate 3 is where the project is given treasury approval. Flexibility in budgeting exists, but only on the front end of the process, before this gate occurs.

Understand Materiality

Your project control office (or, if you don’t have one, your financial controller) can help you understand company thresholds for materiality—the point at which financial variation is important enough to be recorded: The purchase of a box of pens may be considered immaterial, but buying new computers for the team isn’t. The line where immaterial becomes material varies by company. Understanding your company’s threshold, and documenting accordingly, will endear you to anyone making accounting decisions.

Share your domain knowledge with your counterpart in finance; for example, understanding the concept of swapping user stories and reaching consensus on how to handle the practice will avoid the appearance of impropriety. Assure them that if any additional expense from a swap threatens to exceed the materiality threshold, you will escalate it so it can be properly documented.

Speak the Language of Finance

If you are not already familiar with weekly status reports and risk logs, get familiar. Read them. Love them. Fill them out regularly and accurately. Give them to your project management office and they will love you in turn.

Most importantly, if you provide project budget reports or updates, make sure your line item titles and descriptions exactly match the ones you used when the budget was first approved. If the approved budget refers to “Epic: Authentication UI,” then that’s what you should put on your report—not “Epic Login Screen” or any other variation. Ignore this advice and you are guaranteed to create friction and frustration across the entire financial arm of the organization.

Value Delivered

If you meet the financial requirements above, congratulations! You’re fulfilling the C-suite’s need to “do Waterfall.” The capital expenses are properly recorded, and no part of the process has required any change in how code is actually written or how updates are delivered. Any compromises you’ve had to make in planning have gained you allies in other departments and the C-suite. The process has also given you a better understanding of how your team can work with other parts of the organization, rather than toiling in isolation—or worse, working in opposition to those who are supposed to be on your side.

An Agile purist might consider these financial concerns to be “contract negotiations.” However, it’s just as valid to think of your financial colleagues as internal business customers. Meeting their needs on matters of finance is just another form of customer collaboration. And in Agile, the customer’s perception of value delivered always wins.