Feel like a voice in the wilderness in your organization? The Minimum Marketable Feature Set (MMFS) makes so much sense. Who could argue against getting software to market faster using smaller and more frequent releases? Is the business really that dumb that they don’t get it? As a software development engineer having the opportunity to become a VP of product management and a CEO, I’ve been able to look at this problem from all sides.
The MMFS concept has been around for a long time. However, many organizations still plan large releases the way they did in the waterfall days. The Agile community needs to understand the organizational dynamics of large organizations to understand why.
I represent the large segment of the software industry that needs to commit to quarterly revenue and income projections through a sales organization. The first thing to know is that the sales department “rules the roost” in these organizations. They have the ears of the CEO and CFO, whose success depends on the sales team delivering predictable revenue. All it takes is for sales to say, “without that we can't make our revenue targets” and pressure builds on product management to coerce engineering into adding it to their backlog, usually with no schedule relief.
To-date, there have been no negative consequences for sales to ask for the world. Their experience is that the harder they push, the more they seem to get. Now, we know on the development side that this usually ends up with a façade of features that demonstrates the “happy paths”, but the features lack the robustness of the high-quality software the developers want to build (and which Agile promised them).
With this history, sales departments are reluctant to agree to an MMFS. They believe product development will slack off because when they push for more they get more. They want to push for every possible feature that could result in a sale, even if that sale is in Outer Mongolia. This pressure leads to huge releases that take longer and longer. If the sales department doesn’t push for something in the next release train, it will be years before they have another chance, so they push harder and the release cycle time increases. It’s a vicious cycle.
The problem is that there hasn’t been a way to quickly convey the financial value of the MMFS. It looks to the sales department like they have to sell it for less within a smaller market segment. With Agile Investment Planning described in my book, Unlocking Agile’s Missed Potential, an MMFS is represented by an "Agile Investment" that can be related to income. It is possible to demonstrate the financial value of the MMFS.
Let’s say that you’re currently delivering annual releases stuffed with features that generate monthly income of $100K per month after deployment. You’ve determined that you can break the release into two MMFS deployments, each of which can generate half the value at $50K per month. The table below shows the quarterly income profile for the two cases. In the first case, there is no income for the first year while the release is under development. In the second case, income from the first MMFS starts in Q3.
Table 1 – Annual release quarterly income ($K)
Table 2 – MMFS quarterly income ($K)
The MMFS case produces an additional $100K within the two-year period, which is an increase of 100/400 = 25%. Which plan do you think the sales department and your CFO will choose? Of course, the MMFS! Total productivity has increased 25% (value out divided by value in).
This is a simple case to show the relationship between release timing and income. Reinertsen calls this effect the Net Cost of Delay, which was covered in a previous article. Cost of Delay is the cost of delaying MMFS 1 by six months, which is $100K. We can also say that opportunity cost of the large annual release is $100K. My book handles more general cases for non-linear income profiles, such as S-curves. It also accounts for fixed release overhead costs for the additional releases.
In general, cutting your cycle time by ½ will generate 25% more income. Below is a chart from my book that shows the general case of reducing your cycle time of an annual release by various factors (Release Cycle Time Reduction Factor of 12 represents monthly releases).
Robert Webber, Unlocking Agile’s Missed Potential, Wiley IEEE Press, 2022
It’s interesting to note that the productivity gain reaches a limit. The curve reaches a limit of 50% for Continuous Delivery (CD). It raises the interesting question of whether income from CD offsets the additional testing and deployment overhead. I won’t argue that CD has merit in terms of increasing the rate of rapid feedback, but it may not be directly financially justifiable.
So, we’ve shown that when you can quantify the financial value of an MMFS in terms of Cost of Delay, you can show its financial benefits. You can demonstrate financial incentives to adopt the MMFS. The key is being able to assign financial value to the MMFS, which fits the definition of an “Agile Investment” in Agile Investment Planning introduced in my book. If you can’t demonstrate financial benefits of the MMFS, save your breath. It’s not going to happen.