Is Your Financial Process Killing Your Software Quality?

Photo by Blair Fraser on Unsplash

If you are reading this, your company probably produces software, even if just for its own internal use. And that software is probably abysmally bad. It might get the job done, but over time it has become harder and harder to maintain. The people who built it are long gone, and those who maintain it can’t ever seem to get ahead of an ever-growing number of defects.

In short, your software sucks. There, I said it.

But how do we make it not suck? How do we make sure that our software is doing what we want it to do? Agile has, in almost twenty years of existence, answered this question pretty well. We have test-driven development, behavior-driven development, continuous integration, continuous delivery, acceptance-test-driven development, and a whole host of other ways from XP and DevOps to keep quality up while still delivering value to the business.

But what about your funding method? Have you considered what effect your financial strategies might have on the quality of your software?

New Era, Old Ways

Most companies use the same budgeting process that was used sixty or seventy years ago, when manufacturing output made up the bulk of the GDP in the US. These budgets revolved around huge projects that would deliver a final, polished good to consumers. The development of a new project might take a year or more. So it made sense, in that economy, to create financial forecasts based around the Big Project. Budgeting became a yearly affair. Executives were given forecasts at the beginning of the fiscal year, and their annual bonus might depend upon how well they met these arbitrary goals.

This model might have made sense when we were building washing machines, automobiles, machine parts, and other consumer durables, but it makes less and less sense when your economy is largely driven by software. The simplest software is more complex than most refrigerators. Our ability to manage this complexity is always limited by what we know. And it turns out that we never know quite enough.

Software, however, has one thing over the traditional manufactured good: you can keep tinkering with the finished product long after it has left your warehouse and is in the customer’s possession. Thanks to robust communication networks, software can update itself in situ as it occupies space on the customer’s phone or desktop. It can also learn what the customer wants by monitoring requests in real time. To put it into perspective, in 1959 the Ford Motor Company took three years after launching its Edsel brand to realize that customers hated it. Today, we can learn all that and more within minutes.

Agile Delivery… and the Speed of an Annual Budgeting Cycle

Photo by Sho Hatakeyama on Unsplash

Applying Big Project Budgeting to Agile software development simply doesn’t work. It’s not that you have a fast thing (Agile delivery) that is blocked by a slow thing (traditional budgeting); it’s that the slow thing literally breaks the fast thing. It’s like you have a fighter jet and you decided to lash a beached whale to its fuselage. You no longer have a jet; what you have is smashed bits slick with blubber. With Big Project Budgeting, you are literally handicapping your own progress.

With Agile, we have learned how to take a lot of the risk out of software projects. We optimize for small batches. We continuously deploy and integrate. We release on demand. We create minimum viable products and treat them as experiments to gauge customer appetite for more. We learn from and act on real user feedback, not our imagined experience of idealized users.

But all of this goodness is undermined by the Big Project Budget, with its assumption of three-year horizons. In Agile, we admit to ourselves that we do not know what will happen next month, let alone in the next three years. We plan accordingly, using short sprints and quick learning cycles. But all too often, these efforts are undermined, if not entirely discarded by corporate budgeting practices and mindsets.

Take software quality, for instance. Imagine that your teams experiment with test-driven development, and the outcome is very good. The released code is now virtually defect-free in production. The teams can use all that time they used to devote to maintenance to improving and enhancing the software. But then there is a catch: the TDD process takes 35% more time. The software is 95% better quality, but your yearly budget projected that you would have five or six major new services released by the end of the fiscal year. At this rate, you will fall short of that goal – a goal, let us remember, that in most companies would be based on pure guesswork.

Failing to meet the specified goal means that someone very powerful in the organization gets disappointed come bonus time – and this is a person who does not like disappointment. So this executive pounds on a few doors, bangs his fist on a few tables, and lets the IT staff know that it is NOT ACCEPTABLE to miss the deadline. Never mind that the software works better. Ditch the quality initiatives, says the exec both in words and action. Nobody cares how the software works, says the exec. Make it HAPPEN! (And, let’s not kid ourselves: “it” you are making happen is his bonus.)

This gets IT managers stirred up to the point where they pressure their teams to deliver faster. The teams work more nights. They sacrifice more weekends. Tests magically stop being written, for the simple reason that no one has the time to write them. And thus your software goes right back to where it started: it sucks again. And it will continue to suck until it sucks profitability right out of your balance sheet.

This is how a budgeting process designed for pig iron production kills software quality.

Photo by Fotis Fotopoulos on Unsplash

What to do to Make Your Software Suck Less?

The software your teams are building is a strategic asset. Imagine a world in which that software is no longer holding you back. Imagine how many more strategic initiatives you could enable, how many more experiments you could run, how many new customers you could gain and how many existing customers you could delight. Imagine what could happen if your IT staff no longer needed to devote a third of their time to fixing production issues. Imagine if things just worked. Imagine the productivity gains. Imagine your ROI shooting up.

Imagine, in other words, if you had a budgeting process that rewarded your employees for doing it right, not just for doing it fast. It is achievable, if we can find a funding model that does not indirectly kill quality.

Imagine, in other words, if you had a budgeting process that rewarded your employees for doing it right, not just for doing it fast. It is achievable, if we can find a funding model that does not indirectly kill quality.

What we need, and what an increasing number of businesses are coming to realize we need, is a budgeting process that allows us the same level of agility and risk-mitigation that our Agile development methods do. We need shorter horizons, more flexible goal-setting, financial plans that can be adjusted – and not on a yearly cadence, but whenever it is required. This must be a disciplined rather than an arbitrary approach. This is still a business, after all. Most of all, we need financial executives who see the need for change and who can face the challenges with bravery and aplomb.

In a recent blog on the “3 Indicators for Better Business Outcomes,” Daniel Fuller explained the concept of adaptable funding models in this way:

Adaptive funding models and associated governance processes allow organizations to quickly and easily invest in new products or services as soon as market opportunities arise and, just as quickly, stop or change work that isn’t delivering the expected business value.

We see that traditional funding models then aren’t only at the foundation of why most IT-produced sucks; it’s also why business success in other areas stall. Inflexibility costs the organization in lost opportunities, losing investments and customer attrition. By changing your approach to budgeting, by adopting a more adaptable model, you can do so much more than just make software that doesn’t suck.

So: is your team ready to change how you budget so you stop making software that sucks?


Adaptable Funding Models and Business Agility Success

In the 2019 Business Agility Report released by the Business Agility Institute, adaptable funding models was one of the three key predictors of organizations seeing success with business agility. The other two are aligning to value streams and relentless improvement.

Read the 2019 Report