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 agile methodology, you’ll have an ally in the board room.
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 essential to successfully improving software quality and responding 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. After speaking with both financial and software experts, including her own company’s CFO, Lisa Crispin, an agile testing practitioner and coach, is confident that you can make agile an easy sell.
Here are seven tips from Lisa Crispin, highlighted in her post on the Software Quality Connection, to help you sell agile to your CFO.
Click through for seven tips to help sell agile development to the CFO, as outlined in Lisa Crispin's post on the Software Quality Connection.
Before you meet with your company’s CFO, learn about their 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.
In addition to preparing information to educate the CFO about agile, learn effective 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 building 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.” Crispin’s own experience has been much more positive, and she’s spoken with 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 their concerns. Use this pattern to create one-on-one communication with your CFO outside of formal meetings. The Whisper in the General’s Ear pattern guides a one-on-one meeting with an influential manager to explain how agile will impact them. Manns and Rising advise, “Be ready to address the costs and benefits of your idea but don’t overwhelm [the executive] with data.”
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 by 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.
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 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 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 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.
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, but they do nothing to prevent the nasty shock when the release doesn’t happen on schedule. On the flipside, an agile project’s many sources of immediate feedback 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: 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 like anything that shows rates of progress. Agile has these tools; show them off.
When Crispin’s company adopted agile development (a decision by the 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 her company’s co-founder and CFO, Dan Gutrich 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 there!
Too many agile transitions start out with a lot of enthusiasm, but die on the vine. It takes many months, sometimes 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). Gutrich suggests looking back over the first year of using agile development to gauge ROI. When Crispin's current team tallied up the results of their first agile year, they discovered they had delivered even more story points than planned, and the production defect rate was dramatically reduced. Given that they focused solely on quality, not speed, and often struggled as they learned techniques such as TDD and refactoring, these results surprised them, and delighted their 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.
