Wednesday, September 03, 2008

A Real World Example of Analyzing Market Risk-based Prioritization

A post in the Agile Management Yahoo! group has prompted me to make this second post with an example to elaborate on prioritizing and planning for market risk.

Steven Gordon wrote:

This approach seems oversimplified to me. In particular, I challenge the assumption that the low risk items should always be implemented first. For example:

1. A company might not even choose to bother with the market unless they can bank on a successful differentiator. In this case, shouldn’t at least a slice or two of the intended differentiator be developed very early to obtain market research feedback on whether the idea really is a differentiator, whether it is really feasible to develop, and whether it might need tweaking or rejection.

2. A truly innovative differentiator can reshape the market and development vision of the whole product. Such a paradigm shift could totally change how the commodity features should be presented and developed.

I am more comfortable with the general notion that features should be delivered in order of immediate value than risk or risk of change. So, differentiators that have a large impact on how the whole product would be designed or on whether the project is even worth doing have large immediate value.

Here is my reply…

I believe a real world example would help. Let’s imagine we are going to enter the cell phone market. Let’s first define the table stakes commodity features. As entering the cell phone market has a huge setup cost, it will be necessary to offer a broad service attractive to many market segments. As I mentioned today’s post really only deals with a single market segment.

I like to keep blog posts to under 1500 words and I will deal with market segmentation and product mix later. So let’s try to define the general subset of features that represent table stakes for entering the cell phone market.

We will need…

A cell tower network
A deal with a long distance carrier to back haul our calls
A PSTN/SS7 telephony stack and associated infrastructure
Dial-tone
Ring-tone
Call setup across multiple networks
Call tear down across multiple networks
A Billing system with the ablity to bill individual calls and reconcile billing across networks to terminating or originating networks
An SMS Gateway
A Voicemail system
Handsets (one model might suffice but unlikely) with firmware to support voice calling and SMS messaging
Address Book feature on the handset
Inbox Feature on the handset
A support infrasture and call center
A market channel / delivery mechanism - such as a retail network

While we could argue the fine points of this set of features, the evidence from the market suggests that they are broadly correct. For example, if we study the MVNO market entrants in this century such as Virgin Mobile USA. Virgin rents its network from Sprint. At the time the deal was struck Sprint did not offer SMS messaging. It offered a rival service and technology from Qualcomm. Virgin thought it sufficiently important to include SMS that they deployed their own gateway to augment the Sprint network infrastructure.

While other features may be argued as “table stakes” the reality is that they are probably table stakes for specific market segments rather than the general market. This is a common problem with many firms. They do not perform good market segmentation and fail to truly understand which features of their product or service relate to specific segments. As a result they believe the table stakes are higher than they are. Smart market insurgents can exploit this situation by offering bear bones or white label products or services that offer just barely sufficient functionality to a market that needs unsophisticated features. A recent example of this would be the market entry of Google Docs which started life as a barely sufficient word processor that was only slightly more advanced than Notepad.

You suggest that differentiating features should be developed early in order to test them in the market and prove their value and market acceptance. I believe you are confusing research with production development. I believe these are parallel activities. Returning to our real example, let’s imagine a differentiator is picture messaging. It would not be possible to demonstrate this feature on the production network without first delivering the table stakes. Though it is technically possible to skip the deployment of the SMS gateway, there is an issue with market acceptance if the SMS service is not offered.

However, the cell phone operator could test the market for picture messaging using research equipment. A COW (cell on wheels) could be deployed for market research. Typically COWs carry new network technology that is not deployed in production. COWs demonstrating full W-CDMA technology were available in 2001/2002 while most operators are yet to deploy W-CDMA for general use in 2008.

If you are able to deploy a differentiator prior to completion of the all the table stakes features then you simply haven’t done your market segmentation and feature classification properly. The table stakes that remain to be completed are probably related to specific segments and not to the segment where you are testing the new functionality.

You state that value is more important than market risk or risk of change. Really? As recently as 3 years ago, I probably agreed with you but I’ve come to realize that I’m wrong. Why?

First, value is very difficult to define. Value is contextual and context is temporal. At best definitions of value are crystal ball gazing and are projecting value today based on market conditions today. Let’s imagine that a new feature envisaged as a differentiator is planned. Let’s say it is picture messaging and market research suggests that it is worth a $10 per month increment in MRC (monthly recurring charge). The lead time to develop it and deploy it is 18 months. 12 months in to the project a rival network launches picture messaging at $7 per month. What is picture messaging now worth? First it is no longer a differentiator. It is a spoiler. And it is probably not worth $7 per month but somewhat less. Either the price falls, or the size of the market falls because the insurgent stole some of our market share while we waited to bring the feature to market.

Let’s now imagine that the competitor launches the feature early in our development cycle. Say month 2. The feature is a differentiator for a small market niche. Because we are following your strategy of prioritizing value first, we are building this differentiator first. We have started work. Have sunk cost in to it. When the competitor launches we redo our market forecasting and come to the conclusion that the feature is no longer viable. The cost outweighs the perceived gain in the market. So we cancel the feature and order another one. We just wasted valuable energy that could have been used developing a lower risk table stakes, cost saver or spoiler feature that is still awaiting engineering.

Hence, there are two reasons for not pursuing a value first strategy. The first is that value is hard to define and has a high variability to it. The second is market risk that puts the viability of the feature at risk. It’s simply bad use of real option theory to prioritize something before we have enough information to be sure that we want the feature delivered. Technorati tag: Agile, Agile+Management, David+Anderson, Real+Option+Theory

Prioritizing and Planning for Market Risk

Three years ago this week, I introduced a scheme for prioritizing requirements that was aligned with strategic planning and market segmentation and brought some rigor and objectivity to the art of assigning a priority to requirements.

Initially, the scheme introduced 3 classifications: Commodity (or Table Stakes); Spoiler; and Differentiator. Later I realized a 4 category was required, Cost Saver. With two possible sub-classifications of cost saved by the customer (lower cost of operation or displacement of other costs), or cost saved to you the producer of the software / operator of a service. These four classifications have survived almost 2 years without revision and seem to be quite stable. I think of this system as a lightweight, and very fast alternative to Kano modeling.

Since 2006, I’ve been exposed to Chris Matts and Olav Maassen’s Real Option Theory thinking. Some of you may recall I was skeptical about real options after seeing a presentation in Munich in early 2007, that attempted to use the Black-Scholes equation from financial option theory to assist prioritization decisions. I pointed out that we weren’t ready for real options because we couldn’t furnish the equation with sufficiently accurate data. Well the Matts-Maassen approach to real options does without Black-Scholes and is the better for it. Matts-Maassen tells us to push back decisions as far as possible and to gather information, create options and understand when they expire. This helps us to optimize decision making and minimum the risk of a decision being a bad one.

We can treat the requirements in a backlog of features/stories as options. Now we can consider the market risk and likelihood of change occurring to a specific requirement based on its classification. We see that commodity/table stakes features have the lowest market risk. When did you ever hear of the table stakes going down? and that differentiators have the highest market risk.

Figure 1. Mapping Requirement Classification to Market Risk

Commodity features are unlikely to change because the table stakes for market entry never go down. They only ever go up.

Cost Savers are more likely to suffer change during the life of a project but still very unlikely. There is some risk that the cost is mitigated in other ways or that shifts in the market, strategic plan, or go-to-market initiatives of the business may de-prioritize the need to save costs. Hence, there is some risk that cost savers may be dropped from scope or unneeded before the project is delivered.

Spoilers are features being introduced to spoil a competitors differentiator. They primarily protect market share. The main risk with spoilers is that by the time they are introduced they have essentially become table stakes. This doesn’t really affect our planning decisions. What would affect a planning decision would be a choice to focus on a different market and concede an existing market to a competitor with a more compelling offer.

Differentiators are the most risky because they may turn out to be features that the customer will not want. They are essentially experimental in nature. If the customer likes them then they are worth a lot of new profit margin. If not then they don’t produce profits. There is also a chance that a delayed differentiator is in fact a spoiler by the time it comes to market.

Now applying what we know about market risk and using a real options approach to decision making and prioritization, we should delay risky items that are likely to suffer change until the last possible moment. This implies we should code up all our commodity features first and delay differentiators until closer to the release date. This is shown in Figure 2.

Figure 2. Planning a series iterations using market risk and feature classification

[I first presented this material at the APLN Summit in Seattle in July 2008 in response to an audience question and then later as a 5 minute “lightning talk"at Agile 2008 in Toronto.]

I have more to say about this approach as the model presented is somewhat simplistic and only accounts for a single market segment. I also want to discuss how this approach relates to the Minimum Marketable Feature (MMF) approach first presented in Software By Numbers. Chris Matts has been marrying up MMFs, with his Feature Injection analysis technique and Real Option Theory. In a later post I’ll discuss my own views on this and how I see it relating to the model I’ve presented here.

And finally, I’m looking for a name for this model. I’ve kicked around names like Strategic Alignment Prioritization Analysis (SAPA) but I’m not entirely happy with anything I’ve come up with. Please leave your suggestions in the comment box. Thanks.

Related Articles
Prioritizing Requirements, September 6th, 2005
Revisiting Prioritizing Requirements, December 26th, 2006
Why we are not Ready for Real Options, February 20th, 2007
Exploring Real Option-based Software Engineering, February 27th, 2007
InfoQ: “Real Options” Underlie Agile Practices, June 8th, 2007
Technorati tag: Agile, Agile+Management, David+Anderson, Real+Option+Theory, Chris+Matts, Olav+Maassen

Monday, September 01, 2008

What are the right conditions for agile adoption?

For several years, I’ve been promoting the notion that “Trust is the essence of agile.” Others like Clarke Ching have joined that chorus [See Carnival of Trust]. This year, I’ve been articulating that the statement “[We value] Customer Collaboration over Contract Negotiation” was the statement in the Agile Manifesto that really captured this concept. High trust, high social capital cultures allow the overheads of contract negotiation, commitments, audit and arbitration to be eliminated - saving time and money.

But it was back in December 2007, when I was in Belgium for the Javapolis event, giving an evening talk to the Belgium XP Users Group that some of the Dutch attendees came up to me and said, “So, if agile is all about high trust culture and Holland is one of the highest trust countries in the World, why is agile adoption in Holland so slow?” This got me thinking.

The answer came to me early this year, while I was reading Collapse by Jared Diamond. This is a book many claim to have read. It is a best seller. You can get it in many airport bookstalls. But it is one of the most dense and detailed texts I’ve undertaken to read. It took me about 4 months to read it through. But it was worth the effort. The most valuable and relevant insight for us, in the Agile community, I would suggest comes in Chapter 9 during the discussion of the demise of the Greenland Norse.

The Norse were actually in Greenland before the Inuit. They were eventually displaced by the Inuit who were moving south as the Earth cooled in the early part of the 2nd millenium AD. The climate change eradicated the Greenland Norse. The Inuit were not native to the region. They had moved in and displaced the Dorset people to the North some centuries earlier. They rarely encountered the Norse but when they did it led to fighting. Eventually, the Inuit eliminated most of the Norse population in a battle one summer. The following year the rest of the population appears to have perished in the winter. So what went wrong?

It seems the Greenland Norse would not change and would not adapt to changing conditions around them. They remained European. And practiced European farming methods. They had a European structure to their society including a cathedral, bishop, and tribal hierarchy associated with government. They took their lead from these civic and religious leaders. It seems they stopped eating fish early in their tenure in Greenland. Why? No one knows. They maintained a mainly European diet, consisting of animals and crops they farmed. As the climate cooled, the yield from the land would not sustain the animals and crops and they eventually starved to death.

Meanwhile, the Inuit thrived. The Norse had the opportunity to observe the Inuit. There are writings. In fact every Norse encounter with the Inuit appears to be documented. It seems the Norse believed themselves superior to the Inuit who were savages and heathen as they were not of the Christian (Roman Catholic) faith. Hence, the Norse did not value the Inuit or their methods. But the Inuit were thriving. They had fast canoes. They could fish. They ate fish. And they had survival techniques that allowed them to cope with changing conditions. But as the Norse slowly perished they did nothing. They refused to change.

To (perhaps overly) simplify, the Greenland Norse were a conservative culture. They stuck to what they new. The continued to do things the way they always had and they hoped it would see them through adversity. In the end, this conservative approach that was resistant to change and preferred the status quo was what killed them. Had they been a liberal culture, ready to embrace new methods and open to the influence of other people and their ideas, then the Norse may well have adapted and eventually assimilated with the Inuit and lived harmoniously with them. But they didn’t. Refusal to adapt to change killed them. They ceased to exist in the 14th Century.

So, this brought me to the conlcusion that the ideal circumstances for Agile to thrive and gain adoption were in cultures that have both high social capital (high levels of trust) and are liberal (small “l”) in thinking and open to new ideas, new thinking and influence from outsiders. While Holland is seen as a liberal country in several social ways - soft drugs are legalized (regulated and taxed) and so is prostitution - in business Holland is a conservative country. Any Dutch people I’ve discussed this with have tended to nod vigorously.

The other very high trust culture where Agile has struggled for adoption is Japan. Again, despite the goths in Harijuku on a Sunday, in business Japan is truly a very conservative culture.

So where is the broadest Agile adoption in Europe. It’s mainly in Britain, and the Nordic countries. The Scandavian countries (Norway, Denmark, Sweden) are all high trust cultures, though not (I believe) just quite as high as Holland or Japan (or perhaps it is the length of track record that matters - as Holland and Japan have been recognized as high social capital countries for as much as 300+ years). Anyway, why is Agile adoption in the Nordic region higher. Is it because businesses in Finland, Sweden, Norway and Denmark are more open to change? more open to ouside ideas? more open to influences? and generally more adaptable in their outlook to process and business methods? [I’m asking the question. The Scandanavians and Finns reading this can tell me if they agree.] As for Britain, it’s a pretty liberal culture despite its reputation. It isn’t a particularly high trust culture but neither is it a low trust culture.

Meanwhile, the low rate of adoption in southern Europe and Latin countries does seem to be predicted by a lack of social capital in society and/or a conservative approach to business.

What I’m wondering now is whether Agile can become established in low social capital, conservative cultures and it simply takes time, or whether it simply will never be adopted. This would beg the question, will the economies of these countries suffer, as they fail to adapt to change. Will they economically suffer a similar fait to that of the Greenland Norse? As the climate changes will they fail to adapt and instead of being eliminated, simply become 2nd or 3rd rate, with greatly reduced relative economic performance significant drop in GDP per capita ranking compared with other countries, as the 21st Century unfolds?

It will be interesting to watch.

References
Trust by Francis Fukuyama
Collapse by Jared Diamond

Related Articles
Trust is the Essence of Agile, June 25th 2005
Clarke Ching, Carnival of Trust, June 2008
Pascal Van Cauwenberghe, David Anderson on Trust, December 15th, 2007
You are What You Read, December 29th, 2005
Naked Review, Feb 5th, 2006
Dennis van der Stelt, Trust is the Essence of Agile, July 5th, 2005
Technorati tag: Agile, Agile+Management, David+Anderson, Sociology, Trust, Social+Capital, Culture