Continuous what?

Piro4D on

In the DevOps world, there is talk about “continuous integration” and “continuous deployment”.  You integrate on a continual basis (or daily) and you build from the resulting source code and, if successful, deploy it to, at the very least, a development environment.  The application is constantly changing.

There is one thing, however, that has not come up but is as important as either of the other two continuous items.  Something that, if we don’t have it, will severely impact the ability of an organization to be successful.

Continuous funding.

It’s strictly a business item.  Without continuous funding, the product teams need to constantly be going back for more funds to do more work.  This model is counter to everything else that the product team is trying to do, everything that the business is trying to do.  This is about as far away from Agile as you can get.  I’d even go so far as to call it an “anti-pattern“: something you do for one purpose but is ineffective and possibly counter-productive.

There are two things that need to be addressed:  continuous funding of an active program and continuous funding of a dormant program.  (I’m making all this up as I type so bear with me on this.)

Continuous Funding of an Active Program.  Let’s say you’ve got an application that helps you match prospective dog owners with dogs that are up for adoption.  There are five applications that need to be built for all of this to work but, since you are building things in an agile manner, you really only know the details of the first application you’re building and only vague ideas of the others.

In “traditional” (aka old-fashioned) companies you create a business case for application one, get the funding, build the application, release it and then repeat the process for the other four applications.  There is a lot of effort that is involved in building the business cases, all five of them.  And a lot of wasted time between applications being built.  The team is unable to flow from one application to the next as they have to wait for funding.

Instead of funding an application, fund the program.  Give the team $$$$ to build the complete program.  Yes, you don’t know exactly what the final solution is going to look like, no one ever really does.  But you give the team what they think they will need for the entire program knowing that the dollar values for the applications are really just SWAG.  You trust the team to make the right decisions.

And therein lies the key.  You need to trust the people close to the situation to make the right decision.

Continuous Funding of a Dormant Program.  OK, you’ve got your five applications built and people are adopting dogs like crazy.  Now what?  Well, technology changes and your application needs to keep pace.  If you built a mobile app (highly likely) then you need to ensure that it stays current as the mobile ecosystems change.  You need “maintenance” money to keep away that technical debt.

What many organizations do, however, is abandon their app.  “It’s in, it’s running, what more is there to do?”  This is why some organizations have applications that are still running technology that the manufacturer phased out five or ten years ago.  Staying current with technology is not an option.  Like I said the other day “You can pay me now or pay me later.”  Organizations betting that later never comes don’t win the bet.

Every application needs a “Guaranteed Minimum Investment” each year and the team shouldn’t have to create a business case to get it.  The mere fact that an application exists means that some maintenance likely needs to be done.  If nothing needs to be done, congratulations, you just gave some money back to the corporate coffers.  But, if something does need to be done, the team can get to work on it right away without the need for business cases, long approval processes and the like.

Continuous funding (both active and dormant) is necessary for a development team to be responsive to the citizen/client, responsive to the business, and to provide value while value can still be given.  Being responsive means not being a technology laggard.

You may think you’re Agile.  You may think that you are meeting the organization’s goals and objectives.  But if you can’t fund initiatives quickly and completely, then you might as well just throw your money into the wind because you’re not using it effectively.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.