An agile financing model: Agile share-in-savings

(Getty images)


Written by

How can you rewrite a legacy federal software system when you don’t have enough money?

Agile software development produces code iteratively. If we extend the principles of agile software development to the total rewrite of a legacy system, then we must rewrite it in chunks and find a way to finance that rewrite in chunks as well.

Many systems in the federal space are so antiquated and so large that the line count, and yearly maintenance, of the system is much larger than it would be if it were written or rewritten today. We are spending so much on maintenance that we can’t finance the rewrite that would save us money.

We have proposed the following model, which integrates the share-in-savings financial model, the strangler pattern of rewriting a system, and agile software development.

We’ve attempted to represent the whole model in this infographic:

The basic idea is to break the task of rewriting a system into chunks — let’s say 100 chunks of 1% each. It takes an expert to figure out what chunks to rewrite. We call the person who does this a Legacy Refactoring Engineer, and such experts are available within government (for example, Presidential Innovation Fellows, U.S. Digital Service, and 18F) and, of course, through the private sector.

Once identified, each chunk is then bid upon by a pool of vetted vendors. Whoever bids lowest works on it for a short while, such as a quarter, and then submits to a Code Quality Assesor, an expert who evaluates the code based on how much they expect the new code to save the taxpayer in the future. Then the firm gets a small amount of cash, but more importantly they get something new: an Agile Share-in-Savings Asset.

Share-in-savings was invented some time ago, but it has not been integrated with the agile software development in quite this way.

Now the point of this asset is to motivate firms to bid low on this work, in hopes that the asset will pay a great profit later, without the agency having to pony-up a lot of money that it hasn’t been appropriated. In other words, it’s a way to capitalize the future savings.

The asset is paid purely out of actual, realized savings, so the agency risks nothing. That is, the asset entitles the bearer to a small fraction of future realized savings for the next five years. Since it does not depend on the specific chunk the firm worked on once it has been awarded, firms have every incentive to cooperate to maximize future savings (and to compete to get the Code Assessor to assign them as many Agile Share-in-Savings Assets as possible!)

The strangler pattern and the Agile Share-in-Savings model requires something the government is just now learning: continuous integration and deployment of small code chunks. This is “DevOps,” and modern firms have driven it to a nearly hourly deployment.

There are a lot of things that can go wrong in this model. We discuss these in detail, as well as benefits and background, and the history of share-in-savings, after our introduction.

Disclaimer: any of the views or opinions expressed in this article are completely our own and by no means represent that of the federal government’s.

Dr. Rob Read (alumnus) and Chris Cairns are co-founders of 18F. Together, they started and built the team’s acquisition arm, including Agile Acquisition Consulting, Agile Delivery Services Marketplace, RFP Ghostwriting, Micro-purchase Marketplace, and Digital Acquisition Accelerator.

-In this Story-

18F, agile