Those who hold the purse strings like to understand how much money they are going to be asked to dole out and what the potential return of that investment is. The uncertainties of business means that they’re effectively placing a bet, and they sure as heck want to understand if they’re making a small bet or a big bet.
This means understanding the complete picture. Granted, there are uncertainties in software development; what I like about Agile development is that the hard evidence of actual delivery and velocity provides an accurate gauge to base dates and costs on.
When it comes to funding (for most projects), the real decision centers around whether the business wants to continue to fund a given project, which is different than incrementally funding as you go. Stopping a project may mean scrapping everything and cutting your losses.
When halting a project that involves producing a new software product, the risk is that a partial product – even with the highest-valued features delivered first – may not possess enough cumulative value to make the product worth using and supporting. A baseline of functionality must exist; the trick is to determine what that minimum actually is. Most err on the side of including greater functionality than is actually required.
When new features are being added to existing products, you may have a little more maneuvering room to trim features off of a release. Of course you have to keep in mind that shaving too many features off of a release may open the door for your competitors.
This means that an Agile project, just like any other project, needs to forecast features, dates and costs so that the business can make informed decisions. The business needs something to go on. A number of questions come to mind. The first half a dozen that popped into my head as I wrote this:
- What are the objectives of this project?
- How does this project align with the organization’s (corporate) strategic objectives?
- What is the minimal marketable feature set?
- How long is it expected to take to deliver, and what are the anticipated costs?
- What is the anticipated return on investment?
- Is there a critical date that must be met, such as one involving holiday shopping, regulatory compliance, or a major conference where it will be highly advantageous to launch the product?
I'm not advocating that Agile development needs to change its planning. Sizing the user stories, forecasting dates, and gauging planned versus actual delivery by working a couple of iterations (or sprints) is fine. What I'm saying is that Agile development cannot act as a shield and allow teams to avoid these issues. It’s irresponsible. That said, I can think of two cases where incremental funding makes sense:
Projects where the solution is uncertain. These are projects designed to explore options, where the problem is understood – and an opportunity exists – but the solution is not clear. These types of projects may take some technical exploration in conjunction with the business to determine options. This in turn could result in a larger project designed to refine and commercialize the solution.
Projects where you have limited prior experience. Perhaps your organization is delving into new territory. The belief is that you can operate successfully in this new space, but you want to confirm that belief. Incrementally funding a specific project to provide your organization with proof that you can succeed is a great option. If the actual velocity is established as being off the mark enough to drive a project’s timeline and/or costs beyond what is acceptable, the business can elect to discontinue the project.
Incremental funding is a tactic for dealing with high levels of uncertainty. But it is not for every project.