Selling Agile to the CFO: A Guide for Development Teams
Your programming team is on board with Agile and the notion of iterative design and development. But the financial executives prefer to think in terms of “Just tell me when it’ll be ready and how much it’ll cost.” If you can sell the CFO on the methodology your team uses, you’ll have an ally in the board room.
You’ve learned about Agile development, or perhaps you have even worked in an agile organization and have now moved to a traditional one. You’re convinced that by adopting Agile, your team can deliver better value to your business, more frequently, and at a sustainable pace.
But Agile adoption requires a big investment by your company, not just by the development and QA staff. Your team needs time to master Agile values, principles, and practices, and to apply them to your unique situation. A culture of learning, time to experiment, and tolerance for mistakes are a must to successfully improve software quality and respond to changing business requirements. How can you get the resources and long-term support you need from the business?
Here’s a good strategy: Get your Chief Financial Officer (CFO) on board. Telling the CFO, “We want to do this” probably won’t work. How can a developer convince a CFO that Agile development is worth the investment? After speaking with both financial and software experts, including my own company’s CFO, I’m confident that you can make Agile an easy sell.
Many of us have worked in companies where speed was valued over software quality, and development teams were subjected to “death marches” to kick software out the door. It’s easy to become a bit paranoid, but according to my company’s co-founder and CFO, Dan Gutrich, CFOs don’t have an innate distrust of technical teams. You may find your CFO is receptive to your explanation of how Agile development can help your company’s bottom line – especially if you can speak in the CFO’s language.
(Maybe you work for such a large company that there’s no way you have access to the CFO. In that case, substitute “the person who has control over your department’s budget” for “CFO.” Find the right decision maker with whom you can arrange a meeting.)
Consider the CFO
Before you meet with your company’s CFO, learn about her roles and responsibilities. CFOs aim to predict financial performance and the return on potential investments, but often they make key contributions outside of finance. Your CFO may know a lot about all aspects of the business, and may be more interested in software development than you expect.
CFOs are responsible for budgets and controls. They need measurability, transparency, and benchmarks to help plan for and predict future performance. They’re routinely asked to invest in improvements. Be prepared to show how Agile provides an ability to quantify software development where traditional methodologies don’t.
Prepare to Be a Change Agent
In addition to preparing information to educate the CFO about Agile, learn good ways to introduce new ideas. The book Fearless Change: Patterns for Introducing New Ideas [Mary Lynn Manns and Linda Rising, Addison-Wesley, 2005] is one way to improve your chances for success. According to Manns and Rising, it pays to begin to build a relationship with a higher-level manager. “While he may never become an enthusiastic supporter, at least he is less likely to block your efforts.” My own experience has been much more positive. I’ve talked to many teams whose executives offered strong long-term backing for their transition to Agile.
Manns and Rising describe two patterns that work on decision makers and key influencers like your CFO. One is Corridor Politics, in which you informally approach the decision maker, explaining the issue, listening to and addressing her concerns. Use this pattern to create one-on-one communication with your CFO outside of formal meetings. The pattern Whisper in the General’s Ear guides a one-on-one meeting with an influential manager to explain how Agile will impact her. Manns and Rising advise, “Be ready to address the costs and benefits of your idea but don’t overwhelm [the executive] with data.”
Quantify Agile Development Advantages
CFOs need benchmarks, tracking, and financial measurements. Explain how Agile delivers value frequently, in small increments. Incremental development aids in gathering metrics that help CFOs analyze return on investments and plan future budgets. Go over the process of breaking features into small user stories and sizing them with a point system. Over time, CFOs can get a good idea of how much a story point costs. As teams learn, their velocity averages out and becomes predictable.
One way to describe how Agile teams build only what is useful and necessary is to compare the process to just-in-time inventory and the drop shop model for online orders. Manufacturing companies in particular understand the value of building features in shorter timeframes and knowing what they’re getting.
CFOs know that long development cycles are inefficient. The short cycles of Agile – delivering production-ready software in one, two, three or four weeks – provide more certainty. You know what you need to do in the next month. CFOs understand this much better than waterfall development. If software is your company’s most important product, this just-in-time approach is especially important.
Quantify Technical Debt
Many, if not most, traditional software projects (and some so-called “agile” ones) are dragged down by technical debt. If your code is already clean and continually refactored, going into “debt” by cutting some corners to meet a critical business deadline and “paying it back” with later refactoring is a sensible approach. If your code is a nightmare of brittle, mysterious code that isn’t supported with automated regression tests, cutting corners is even more likely to lead to disaster. Even the smallest code change might result in dozens of regression bugs, paralyzing the project.
Managing technical debt is a compelling justification for adopting Agile. A whole-team and whole-company commitment to quality along with Agile practices such as refactoring, test-driven development (TDD), Acceptance Test Driven Development. (ATDD), and continuous integration (CI) helps teams start chipping away at their technical debt.
The ability to quantify technical debt, according to my company’s co-founder and CFO, Dan Gutrich, is music to any CFO’s ears. In The Financial Implications of Technical Debt, Jim Highsmith points out that technical debt’s impact is often slow-growing and hidden. CFOs understand the concept that technical debt increases the cost of change over time, so be prepared to explain how an investment in reducing technical debt pays off with consistent, predictable delivery of value. Agile practices such as refactoring and TDD help manage technical debt and allow the team to sustain a maintainable pace as they deliver value frequently.
Israel Gat explains how to calculate your current level of technical debt in the October 2010 Cutter IT Journal issue on Technical Debt. His process starts with code analysis and identifying quality deficits, then discusses estimating the time and money needed to fix the deficits. He states, “Once technical debt is monetized, its operational, financial, and business implications can be understood and appreciated by any stakeholder.” A CFO will have no problem relating to a statement like “the technical debt on the project amounts to $500,000.” (I could write far more about technical debt; if you’re interested in reading more, I recommend the Cutter IT Journal issue on Technical Debt.)
Do your homework, learn how to quantify your technical debt, both in the production code and in the automated tests (or lack thereof), and present the results to your CFO. Be ready to discuss why higher quality and fewer bugs directly affect the bottom line. Should your company invest time and money to reduce technical debt, versus spending lots of time and money to fix production bugs while new development is slowed? It’s a simple choice for most CFOs.
In organizations that practice phased-and-gated development, CxOs live in blissful ignorance of software project progress until the release date, when they learn that the release has been postponed. In Agile organizations, the CxOs may sometimes experience the panic of looking at a task board mid-sprint that has too few cards moved to the “done” column – but they much prefer that to unpleasant last-minute surprises.
The difference between Agile and traditional projects is dramatic from the CFO point of view. In a traditional project, with long release cycles, there’s no way to know the status of the project on a daily basis. Project managers might have Gantt charts or project plans, which might be reassuring to non-technical CxOs, but these do nothing to prevent the nasty shock when the release doesn’t happen on schedule. The many sources of immediate feedback on an Agile project provide CFOs with much more certainty and predictability.
Demonstrate Agile’s many “big visible charts” to your CFO. Show how the project’s current status is visible in many ways: release and sprint burndown charts, task or Kanban boards showing what’s done, what’s in progress and what’s blocked, results from continuous integration. Even if an iteration goes awry and some user stories are not completed, the reasons can be identified immediately with retrospectives, and the project can get right back on track. CFOs (and any other kind of “bean counter”) like anything that shows rates of progress. Agile has these tools; show them off.
Continuous integration is an agile practice that’s essential for any team. With some initial education from you and your team, CFOs understand that the number of tests at the unit, API, and GUI level should increase over time, and that they should all pass. In my team’s early days of practicing Agile, our managers got reports of daily build success. If tests failed two days in a row, our CFO noticed and asked about it. Quick, visible feedback lets the CFO know projects are on track.
Explain to your CFO that the development teams will collaborate closely with business experts, gaining much domain knowledge. The developers will be much more likely to understand customer needs for each user story and feature. This reduces churn and helps the team find better software solutions.
The idea of limiting work in process, and ensuring each story is done (including testing activities) before moving on to the next story should make sense to any CFO. We can’t know for sure how much work is left to do, but we know what we’ve finished.
An Additional Sales Pitch
When my company adopted Agile development (a decision by our CEO and CFO), the methodology was relatively rare, practiced by only a few teams. Now Agile is mainstream, used in many companies of all sizes and in all industries. As Dan notes, this means that practicing Agile has become a recruiting and retention tool for Human Resources. Just as CFOs are aware of incentives to attract and retain salespeople, they want to hire the best developers as well. The chance to recruit the most talented developers is another good selling point: People will want to work here!
Too many Agile transitions start out with a lot of enthusiasm, but die on the vine. It takes many months, even more than a year, to get traction on practices such as driving development with tests. Everyone involved has a lot to learn: programmers, testers, business analysts, and project managers. Plan for feedback throughout the process, and hold retrospectives at frequent intervals (at least every iteration).
For the CFO, that means measuring progress and return on investment (ROI). Dan suggests looking back over the first year of using Agile development to gauge ROI. When my own current team tallied up the results of our first Agile year, we had delivered even more story points than planned, and the production defect rate was dramatically reduced. Given that we focused solely on quality, not speed, and often we struggled as we learned techniques such as TDD and refactoring, these results surprised us, and delighted our CFO.
Your Agile transition won’t always be smooth sailing. Even as the years pass, new challenges will arise. By this time, you’ll have built trust with your CFO and business experts so that they will continue their support. Don’t take anything for granted. Keep using appropriate measurements and quick, visible feedback to guide your continual improvement.