Manage risk. Despite having backlogs, Agile doesn't manage risks--explicitly. In 2007, Paul Kedrosky noticed a rather peculiar ratio. The ratio of software developers to non-developers at a major quant fund versus a major software company:
- Oracle (56,000 empl.) -- 1:8 (one developer for every eight employees)
- Renaissance Technologies (178 empl.) -- 2:3 (two developers for every 3 employees)
It's not too much of a stretch to say that hedge funds are a new type of Software Company. After all, they have more developers per capita than the latter, and they generate more cash flow per capita, if they are any good. Hedge funds also provide a fantastic template for how software companies and projects could be run. Risk management separates the men from the boys. Well-run hedge funds make financial decisions quickly, consistently with the spirit of the agile manifesto. They cannot afford to let any bureaucracy get in the way of “high gamma” execution.
In fact, a hedge fund is just a company too, with the main difference being that they have a disproportionately large pool of capital to invest in the markets. As a thought experiment, I explore hedge fund approach to investing to new software projects, specifically to compare a waterfall approach to an agile approach. All software investment projects have embedded real options. Many analytical tools exist when investing with options, and many of them are surprisingly relevant in a new product development context.
Every greenfield software development project, from the moment it's just an idea discussed by the team, is a bet on what clients or prospects want. Even if the project is being custom made-to-order for one client, it's possible the client's actual needs will be verbalized differently, once he sees a prototype. In addition to technology unknowns, development projects also face a number of other unknowns, especially in the context of marketing. Who exactly will need it? What problem will it solve for them? How many potential users exist? How do we effectively find and convince the potential users to buy this software once it exists? That's why it's reasonably easy to understand new product development as a bet the product team makes.
Don't make detailed assumptions about the distant future.
Like tax returns, project plans in software development are largely intricate works of fiction, i.e. based on a true story. Instead, you can make supremely detailed tactical short-term plans, where:
- your context doesn't have time to change as much
- you can integrate your product development as quickly as possible with paying customers
- you can prove that a market exists for the new product, and that the concept is even viable
You are trying to discover an unmet need in the market which your prospects will be crazy about. Then, you actually have a chance that your bet will turn into a Demarco Project B. Then you will be thinking like hedge fund, really understanding and calculating the value of your immediate real options.
In this case, you are investing in a real call option. You have a small initial outflow at the beginning of the project, to generate a minimum viable product. Your losses are limited to that outlay. Your net present value (NPV) will be negative. Based on the standard criterion for accepting an investment project, you should reject such a project if the NPV is less than 0. Nevertheless, within a few iterations, you may generate a product that starts generating revenue. This revenue stream may exhibit exponential growth. In financial option terminology, the real call option has high gamma.
What does this mean for you operationally?
If you are using an Agile approach, you already keep track of your call options in a product backlog. A product backlog is an ordered list of potential features, or user stories, for a product. In the context of a new product, the product backlog's most important function is to help you, as the product/business owner, prioritize this list, primarily based on the expected payoffs of adding a feature. Once you finish enough of a product that you can sell it, you start getting a lot of feedback about everything but the development process, so it would be ideal to have the flexibility to adapt to market conditions.
This list, while it may look rather dull, is potentially revenue-generating magic in the future. In fact, you can view it as a list of real call options, like the exchange traded derivatives variety. A backlog is effectively a portfolio of real options. An option portfolio is more dynamic. Its value depends on your business context. A number of interesting implications come out of this new model.
In fact, this is where Agile and Scrum metaphors around the backlog as a “feature idea inventory” break down for me. Typically, the product backlog is described as an inventory of potential features, where they are hoarded and stored. In my mind, a warehousing metaphor is somewhat lifeless and static. You don’t take into account the potential features’ value, when doing NPV financial analysis.
After getting an understanding of the market where a company operates, VCs just calculate a “fudge factor”, as a proxy for how much they believe the company will actually generate revenue. They use the denominator to override the value of the company’s real options on the product backlog. The value of these options will effectively decide whether the project will be a Demarco Project A or Project B, yet they aren’t taken into account explicitly at all.
In a high-tech environment like IT startups, return on investment (ROI) is more likely to be driven from adding new revenue streams than from controlling costs and budgeting. From an income statement point of view, the top line (revenues) is much more important than the bottom line (net profits), because we work in such a young and rapidly expanding industry. You can use NPV to trace cash flows down to combinations and series of tasks, and to estimate when you might be able to start selling in the future. Alternatively, you can also explicitly value your backlog items as real options. This way, you keep track of one list of fully developed features you need, so that you can prioritize much more dynamically-as you start selling and getting market feedback.
As a result of taking into account these dynamic scenarios, you have a much more accurate project valuation, at any point in time after the first calculation period used for the estimation! Moreover, NPV on its own systematically underestimates the value of most software and internet R&D projects, because it ignores embedded call options in the product backlog, which typically have high values in a volatile industry. If you calculated their value, and added it to the NPV cash flows you estimated, you can then use the NPV criterion of being net position with more precision. You will be taking into account the true value of what you get, when you invest in that project.
This is the key business difference between agile and waterfall. Waterfall handcuffs you into making estimates of a long term NPV, without explicitly allowing for optionality. Thinking about a product backlog as a portfolio of options is a much finer-grained approach to risk management, particularly when combined with software demos at the end of iterations. Then, you can legitimately claim you run your software project portfolio like a hedge fund manager.
Statistician E.P. Box quipped, "All models are wrong, some are useful". I would add that some models are more useful than others.
No comments:
Post a Comment