Let’s talk about DevOps, CFOs

CFOs, we need to talk.

It’s a bit awkward. You’re in finance. I’m in development. We mostly see each other at budget time.

But that’s actually what I wanted to talk about. There’s something I’ve been meaning to get off my chest.

Your budgeting process is broken. Proposals are out of control. Metrics are out of whack. Everyone is competing for amounts of money larger than they need. The way you’re allocating resources is fundamentally at odds with the way your business wants to work.

If your organization is like many big enterprises, you probably spent the better part of the last 15 years cutting costs by consolidating your data center operations and pushing everything you could offshore. You created detailed waterfall plans and threw them to overseas development teams who built everything 100% to exactly what was specified, nothing less nothing more. When the business wasn’t happy with the end result, the off-shore company change ordered you to death. Since all the activity was happening out of sight, you created an array of metrics to monitor projects to the nth degree feeling as though it would guarantee a better result.

But that’s not how IT works anymore. Agile, DevOps, mobile and cloud made development cycles shorter and more iterative. They reduced the cost of failure while increasing the business upside. Old practices designed to hedge against risk are now protecting very little, and in fact are actually hindering your digital transformation.

Suppose a few people on the business side have a great idea about how to bring in more revenue. To execute, they just need to hire a few developers and spin up some containers in AWS. But then they confront a budget process built around an annual battle for huge buckets of money. The only way to get funding is to latch onto a high-ticket project in roughly the same area, and hop between whichever projects seem to have the best chance of approval. With luck, they’ll get what they need. More likely, they’ll give up. It’s an exhaustive and demoralizing process. It’s no way to innovate.

Can Finance become Agile too?

You already know your business wants to transform around cloud, mobile and the Internet of Things, and DevOps and Agile development. The question is, can Finance become Agile too? Can it create models involving smaller increments of time, smaller buckets of money, shorter development cycles? Can it focus more on revenue growth and less on cost-cutting? Can it live with a little uncertainty?

With Agile, you always know where you’re going, but you don’t know exactly how you’ll get there. That can be a challenge. As Gartner observes, “The lack of a detailed plan, fixed budget and specific milestones makes many corporate leaders, but especially the CFO, feel there is no ‘contract’ — that is, if we give you this money, we'll get this software in return.”

But Gartner continues, “Agile development isn't the Wild West and teams do have metrics to measure how they are doing. These metrics focus on results and the trajectory toward objectives, rather than productivity measures such as lines of code per day.”

Unfortunately, Agile projects often get saddled with exactly these sorts of metrics, which measure outcomes rather than outputs: service-level metrics, high-priority x%, medium y%, how many defects to QA, how many from QA to UAT to production, a multiplier for every percent outside the SLA.  It’s a nightmare of endless spreadsheets designed for massive overseas projects where it’s all about cheap manual process—complete overkill for small, onshore, developer teams who value automation and running lean. If it’s not immediately useful, and doesn’t require manual effort we have to make a decision between cobbling together the TPS report, or working on coding the next story. Guess which one the developer is going to choose.  

DevOps is another casualty of the traditional budgeting process. It doesn’t create products. It doesn’t generate revenue. It doesn’t lop millions of dollars out of operations. However, it makes development and operations faster and more efficient. You can compare it to QA. No one would dispute the value of quality-control, even though its benefits are hard to quantify. The same should be true of DevOps as well, but too often it goes begging at budget time.

Accept uncertainty up front for longterm clarity and reliability

I understand, for finance, nothing is worse than being off target and behind schedule. But by accepting a bit of uncertainty up front, over the long run you’ll get more clarity with Agile and better reliability with DevOps. By working in smaller increments, you’ll incur less risk and get more feedback, sooner, on what works and what doesn’t. If things go wrong, you’ll have plenty of time to make course corrections. Best of all, the business will be able to test hypotheses and explore new directions rather than just looking for opportunities to cut costs. 

Remember, you don’t realize any return on investment until the code is in production. If you can build and deploy in smaller increments, that means realizing your ROI in months, not years.

Look at old-line retailers vs. Amazon. The old line is trying to stay alive by cost-cutting into oblivion. Amazon is innovating quickly and generating new revenue. You probably don’t need to me to tell you which is more successful—or which side your CEO would rather be on.

As published in InfoWorld