The Agile Executive

Making Agile Work

Posts Tagged ‘Christensen

Implications of Technical Debt Uncertainty for Software Licensing Negotiations

with 2 comments

A few years ago, my friend Sebastian Hassinger characterized the state of affairs in enterprise software by the following chart a la Christensen:

The key point this charts gets across is that Open Source Software is becoming “good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By so doing, open source software will steadily gain ground from traditional enterprise software vendors.

Consider this chart from a buyer’s perspective. Functionality (the vertical axis in the chart) can be thought of as value. Whatever the value might be, it is diminished by technical debt in the software as the debt manifests itself as application crashes, degradation of  performance and possible corruption of customer data. Everything else being equal, an application with lower technical debt per line of code is preferable to an application with a higher technical debt per line of code.

Traditional enterprise software vendors do not typically provide the technical debt data for the applications they sell/license. In contrast, a customer can carry out his/her assessment of technical debt straight off the open source code. For example, colleague and friend John Heintz carried out the following technical debt analysis on the Cassandra open source project:



As demonstrated in this chart, any customer can measure the level of technical debt in an open source software he/she considers. For better or worse, there is no uncertainty about the amount of technical debt the customer will need to live with in an open source software. In contrast, a customer will usually need to live with  uncertainty about the level of technical debt in proprietary software.

Uncertainty has economical consequences. For example, testing a product increases its value because it decreases operational uncertainty. The economical value of uncertainty about technical debt is conceptually depicted in the figure below in which value is adjusted in accord with the knowledge or lack thereof of the amount of technical debt. Please note that the following equation holds for the various intersection points on the Enterprise Customer Requirements line: {T3-T2} < {T1-T0}. What this equation means is that under conditions of uncertain technical debt open source software is becoming more attractive than proprietary software faster than it would without taking technical debt uncertainty into account.

Action Item: Before licensing an enterprise application or renewing an existing license, ask the vendor for technical debt data for the application and the plans to reduce the debt. If the vendor refuses to disclose this data or can’t generate it within a reasonable amount of time, ask for the number of open bugs against this application in the vendor’s bug data base. Use either kind of data to drive down the price. Consider  an open source solution (even if it provides less functionality than the proprietary software product) if the vendor you are dealing with refuses to disclose either the technical debt data or the number of open bugs in the enterprise application.

____________________________________________________________________________________________________

Negotiating a major enterprise software deal? Let me know if you would like assistance in bringing up technical debt issues with the vendor to help with negotiating the price down. Click Services for details and contact information.

____________________________________________________________________________________________________

Only 10%

leave a comment »

Readers of the posts Customer Intimacy and Enterprise Software Innovator’s Dilemma might recall two observations made in this blog:

  • The dissatisfactory state of affairs in enterprise software as characterized by Crawford and Mathews in their description of Consumer Underworld relationship between vendor and customer:

Ignore my needs… Be inconsistent, unclear, or  misleading in your pricing… Offer me poor quality merchandise and services that I can’t use… Give me a reason to tell my friends and relatives to stay away…

Open Source Software is becoming ”good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By  so doing, Open Source Software will steadily gain ground from traditional enterprise software vendors

In a Viewpoint published in the July 2 issue of BusinessWeek,  former Harvard Business School professor Shoshana Zuboff cites the following statistics:

…  only 10% of Americans now saying they trust large corporations, according to the Apr. 8 edition of the Financial Trust Index. Some 77% of Americans say they refuse to buy products or services from a company they distrust, according to the 2009 Edelman Trust Barometer. [Highlights by IG].

The statistics given by Zuboff link the two observations cited above. One might argue that Crawford, Mathews and Zuboff deal primarily with consumer behavior, not with procurement of enterprise software. True that this argument might be, I sincerely doubt that the two worlds can be kept apart. At least some of  the folks who license and use enterprise software must be represented in the data given by Zuboff and are likely to act accordingly in their corporate roles. Moreover, her statistics seem to be quite consistent with the recent warning to high-tech issued by Christensen:

If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.

Rusty Automobiles

with 3 comments

No, this post is not about today’s GM bankruptcy filing. Rather, it is about coming to terms with a phenomenon similar to rust – software decay.

An IT application development team I met with recently indicated they reached the point of allocating 80% of their resources to software maintenance.  Various colleagues of mine report similarly worrisome figures experienced in their practices. As a matter of fact, some of  my colleagues consider such figures endemic.

It might indeed be hard to visualize a rusted line of code. Decay, however, applies. To quote Capers Jones:

All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.

Hazardous that software decay is operationally and economically, it is lethal once it becomes embedded as a revenue generator in the business design for enterprise software. In particular, high maintenance costs as part of planned obsolescence  invariably lead to the sorry state of affairs characterized as “Consumer Underworld” in The Myth of Excellence.

If you find this post a bit dramatic, please read Christensen’s recent post on the titanic efforts to turn things around launched by GM when it was already too late. Christensen concludes his post with a very pointed warning:

If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.

Written by israelgat

June 1, 2009 at 1:24 pm

Marauder Strategy for Agile Companies

with one comment

Colleague Annie Shum sent me the URL to a recent post by Clayton Christensen in The Huffington Post. In this post Christensen characterizes “disruption” in the following manner:

Disruption is the causal mechanism behind the “creative destruction” that [economist Joseph] Schumpeter saw so pervasively at work in capitalist economies. [Links added by IG]

Christensen’s post is largely about the automobile industry. It, however, ties nicely to an email exchange Jeff Sutherland and I had about Agile as a disruption inside the company vis-a-vis its intentional use as a disruptive methodology in the market. To quote Jeff:

We are starting to see organizations like yours that can use Scrum to disrupt a market. There is a tremendous amount of low hanging fruit out there. Dysfunctional companies that can’t deliver. I’ve been recommending a “Marauder” strategy to the venture group. Find a company who has a large amount of resources. Set them loose like pirates on the ocean and they seek out slow ships and take them out.

Carlota Perez, who has been often cited in this blog (click here, here and here), is a disciple of Schumpeter. I really like the way the “dots” are connected: Schumpeter –> Perez –> Christensen –> Schumpeter. Their theories of disruption and constructive destruction express themselves nicely in the business design proposed by Jeff.

Enterprise Software Innovator’s Dilemma

with 10 comments

In his classical book The Innovator’s Dilemma, author Clayton M. Christensen introduced a framework for analyzing disruptive technological changes. The framework is based on four principles, as follows:

  1. Companies Depend on Customers and Investors for Resources.
  2. Small Markets Don’t Solve the Growth Needs of Large Companies
  3. Market that Don’t Exist Can’t be Analyzed
  4. The Technology Supply May not Equal Market Demand

Christensen illustrates how the four principles apply to computers, retailing, pharmaceuticals, automobiles and steel at various critical junctures along the road. In the software industry, Netscape’s web browser technology is an enlightening example of disruptive technology in action.

Enterprise Software Innovator’s Dilemma

A couple of years ago, my colleague and friend Sebastian Hassinger characterized the state of affairs in enterprise software by the following chart a la Christensen:

Enterprise Software Innovator's Dilemma

The key point this charts gets across is that Open Source Software is becoming “good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By  so doing, Open Source Software will steadily gain ground from traditional enterprise software vendors.

Strategic Implications for the Incumbent

The maturation of Open Source Software forces incumbent software vendors to seek differentiation for their proprietary products. Such differentiation usually attempts to follow one or more of the following three patterns:

  • Strategy of fear, uncertainty and doubt (FUD), portraying open source products and the communities behind them as not quite appropriate for mission critical applications. As the open source community has been tackling more complicated problems and producing increasingly sophisticated  products, the FUD strategy has lost much of its effectiveness.
  • Functional differentiation through features that are not available in open source products. This kind of differentiation loses much of its effectiveness once the “good enough” open source software line in the chart above intersects with the enterprise customer requirements line (the purple line in the chart). The extra features might indeed be included in the proprietary software, but the incremental value to the customer diminishes.
  • Customizing proprietary software offerings to the particular requirements of top customers. This differentiation stratergy is discussed in the next section.

IT Services

Given the ineffectiveness of the first two strategies to deal with Open Source, various incumbent enterprise software vendors try to protect their business by way of customizing their vanilla offerings to the particular environments, needs and use patterns of their top customers. Such customization  is typically done through professional services engagements for which the customer usually pays. Under this business design, IT service revenues – professional services as well as customer support – often become more important than product revenues. The attach rate - the ratio of service revenues to product revenues tends to hover in the 100- 400% range. In other words, for every dollar a sales rep brings in, in the form of product revenue, he is expected (and often goaled) to bring as much as one to four dollars in service revenues.

Although a high attach rate might be attractive from a revenue stream perspective, it is counter strategic on three critical accounts:

  • It completely distorts the economics of the product – a $1 product could  for most practical purposes cost $2-5. Readers of the Customer Intimacy post in this blog might recall the characterization given by Crawford and Mathews to Consumer Underworld relationship between vendor and customer: “Be inconsistent, unclear, or  misleading in your pricing”.
  • It accentuates the customer frustration with the enterprise software model, tilting the balance further in favor of Open Source Software. IT services are seen for what they often are –  complementary business to unsatisfactory enterprise software.
  • The attach rate dives like a rock in difficult economic times such as the current macro-economic crisis. The phenomenon is described in the recent MGI Research article on the subject.

Agile Based Market-of-One

Hyper-productive Agile teams are sure-footed in moving requirements back and forth between release and backlog. This flexibility in changing the release contents quickly can be channeled toward customizing software to the needs of top customers straight from the R&D lab. Instead of doing it through professional services, R&D tailors custom releases.  In other words, the enterprise software vendor produces markets of one in an efficient manner through Agile methods. If these efficiencies are passed on to the customer, the customer-vendor relation with respect to price could be transformed from Consumer Underworld all the way to Customer seeks the Company.

Although the development of market of one software through Agile methods in the lab can be quite effective, its distribution, deployment and subsequent operation in the customer environment need to be equally efficient. The “containerization”, distribution and provisioning of the output of hyper-productive Agile teams enables the achievement of end-to-end agility. This topic will be explored in forthcoming posts with special emphasis on three important business aspects, as follows:

Written by israelgat

January 27, 2009 at 9:45 pm

Choosing Between Two Disruptions

with 2 comments

A couple of weeks ago I was talking shop with a colleague of mine – the co-founder and CTO of a fascinating software company. He was bemoaning the paralysis that was affecting his company. Every executive was playing it safe, too safe. It was next to impossible to finalize their CY2009 plan as no executive would give hard commitments, let alone be aggressive about making commitments. My colleague was worried. Big time.
 
The fascinating thing about our conversation was that my anguished colleague was quite bullish about Agile methods. His was an informed bullishness – he is a very astute developer who grasps the potential of Agile in a deep manner. While worried about the financial crisis working its way from Wall Street to Main Street, my colleague was quite willing to invest in Agile methods in more than one way. It was intuitively clear to him Agile is not only a good risk to take, it is the right kind of risk to take these days.

The Risks of Introducing Agile

The risk you take rolling Agile on a large scale is the possible process disruption you introduce in your company. There are several risks; at the top of the list:

  • R&D productivity could go down before it goes up.
  • Marketing might be hesitant to promote features that are not 100% guaranteed to be in the forthcoming release.
  • Sales will need time to elevate the playing fields from selling function/feature to selling value.
  • Customer Support must revise support policy to accommodate frequent releases.

I would not take any of these risks lightly. Any one of them could get you and your company in serious trouble.

 
I would, however, suggest you look carefully into the nature of the Agile disruption. Like a set of nested Russian dolls, the disruption to your company’s established modus operandi masks the disruption Agile creates in the market. When it comes to Agile, you face the Innovator’s Dilemma in the Christensen sense. 

 

The Risks of Avoiding Agile

As software becomes more and more pervasive, it does not really matter whether you are in Information Technology, Financial Services, Transportation, Retail or any other vertical. The strategic question you need to consider is your company’s competitive position in the market vis-a-vis rivals who will successfully adopt Agile:
  • How would you cope with a competitor who is much faster to market than you?
  • How would your cost structure be viewed by industry analysts when your rivals rip the benefits of hyper-productive Scrum teams?
  • Would your brand be negatively affected if you fell behind on quality? 
  • How would your strategic customers assess your response time to requests for enhancement compared to nimbler players in the field?

While Agile may cause what seems like negative disruption internally, the need for so doing is often dictated by a corresponding disruption in your markets, where you can’t choose to avoid the disruption. You need to do a risk assessment of the internal disruption Agile might cause versus how you will be affected by market disruption if you do nothing, or something other than Agile.

Written by israelgat

January 13, 2009 at 10:26 pm

Follow

Get every new post delivered to your Inbox.

Join 38 other followers