The Agile Executive

Making Agile Work

Posts Tagged ‘Transaction costs

A New Chasm is Forming

leave a comment »

http://www.flickr.com/photos/96483949@N00/192144459/

Recently I had frustrating experiences with the bureaucracies of two companies: a company who is bringing me in to consult on continuous value delivery and another company who is interested in a seminar on the consumerization of enterprise software. While the two companies could not be more different, good-hearted engagement managers in both companies cautioned me in advance that their bureaucracies would drive me nuts. Based on my experience to date they were not kidding…

It is a striking contrast between the ease with which I can get precious data from my social network anytime I need it versus the unbelievable waste of time answering the very same question in two or three redundant forms used to screen me as a supplier. This contrast leads me to conclude we are witnessing the formation of a new chasm. It is between companies who stick to their old bureaucratic patterns with respect to suppliers versus those that realize that a supplier these days is a “prosumer.” He/she might provide services one day, consume (other) services the other day.

The business opportunity this chasm presents is providing efficient marketplace infrastructures. Anyone who can collect my data once and provide it as needed to multiple companies I interact with as a supplier will be doing me, and countless number of social networking aficionado, a huge service. Time is simply too precious to be wasted typing in the maiden name of my mother multiple times.

The distinguished economist Ronald Coase perceived reduction of transaction costs as the essence of the firm. His thoughts of more than 70 years ago are right on these days. The bar for transaction costs is “fill in the details only once”. Once in this context means “once in your lifetime.”

Recommendation: Examine the  way your company acquires new customers versus the way it brings aboard suppliers. Something is wrong if your company’s procurement folks routinely tell suppliers “we know you have already given this information, but ‘they’ would not accept it from ‘us’ if you don’t fill this extra form as well.” This being the case, you need to rethink your approach to composite value chains.

Written by israelgat

October 13, 2010 at 7:40 am

Agile Contracts

with 2 comments

Pragmatic programmers have been wrestling with Template Zombies– folks for whom form takes precedence over content – since time immemorial. The fight has intensified in the late 1990’s and early 2000’s as Agile methods got traction. This tension can now be seen in Agile contracts: precise and definitive contractual language does not easily lend itself to expressing fluid Agile concepts which rely on “infinite” number of feedback loops. This difficulty manifests itself as transaction costs. In particular, the bargaining costs and policing costs associated with Agile contracts can be significant. The number of contract types summarized in Alistair Cockburn‘s list of Agile contracting ideas is illustrative of how tricky it is to wrestle an Agile contact to the ground.

Building a Contract around Agile Principles

As indicated in the post The Core Principle Behind Agile, the effectiveness and efficiency of Agile is based on doing the most important things at any point in time. Hence, an Agile contract must preserve this principle. After all, what is the point of developing software in an Agile manner if the most fundamental Agile principle cannot be contractually adhered to in an economical manner?!

The key to solving this riddle is understanding the fundamental risk each party is striving to minimize:

  • The client needs to minimize market risk – the software is being contracted to accomplish some business or market objective
  • The Agile provider must minimize delivery risk

These two perspectives do not actually conflict with respect to changing the software along the way. As a matter of fact, being able to change product definition during the development cycle is in the client’s best interest in a world of constant disruption. For the experienced Agile software provider, changes from one iteration to another, sometimes from one day to another, are anyway a standard operating procedure. As long as the Agile process does not change, the delivery risk need not get out of hand.

It follows that the fundamental question under investigation here is the construction of a suitable vehicle for enabling requirements to change during the development cycle without getting bogged down in tedious inter-company bargaining and policing processes. Change in itself is not the core issue.

Money for Nothing

In an Agile 2008 presentation entitled “Money for Nothing and Your Change for Free”, Jeff Sutherland described a novel Agile contract. It is a fixed price contract that allows the client to terminate it at any point in time. When the client terminates a contract, he is only billed for the remaining 20% of unbilled contract value.

The phenomenon on which the money for nothing contract is based is exponential accumulation of value in highly productive Agile teams versus linear payment terms. In the “50-90” case discussed in The View from the Executive Suite post, the customer would be billed for 60% (50+0.2X50=60)  of the contract value. The corresponding accumulated business value for the client at the point of contract termination is 90%.

Your Change for Free

In addition to permitting early termination, Sutherland’s scheme allows substitution. The customer can add or change requirements on the fly as long as he is willing to de-commit an equivalent amount of labor. Upon presenting a new requirement, a new story card (call it X) will be added to the release to implement the new requirement. In return, a couple of less hefty story cards (call them Y and Z) will be moved from the release to the backlog. The contract terms do not change. The contract administrator merely notes that X will be implemented instead of Y and Z.

The Firm, the Market and the Law

It is fascinating to consider the money for nothing scheme in the context of the concepts introduced by Coase in The Firm, the Market and the Law. Using the termination and substitution clauses described above, Sutherland reduces Coase’s costs of the price mechanism to the level that makes the Agile contracts viable in the market. How appropriate it is that the reduction in the cost of the price mechanism is done in the context of Agile methods that strive to reduce cost!

Written by israelgat

January 29, 2009 at 1:19 pm