Archive for the ‘Agile Contracts’ Category
Threads from Washington, DC
Rally’s July 23 Agile Success Tour in Washington, DC was somewhat unique demographically. About 50% of participants work for the government. Moreover, many of the commercial enterprises represented in the event derive a significant amount of their revenues from federal government contracts. The Agile challenges encountered by these folks reflect practices that are not necessarily applicable to “pure” commercial environment. For example, one of the participants asked me about Agile for a project of 500 developers/testers in which her company is the prime contractor for 100 subcontractors! (Recommendation: must devise a business design enabling her company to profitably invest in laying a joint Agile infrastructure across all these subcontractors. Such infrastructure leads to standardization of the Agile data. Click here for details).
In spite of the different demographics, most of the Agile issues brought up in DC were quite similar to those expressed in previous Agile Success Tour events. The bureaucracy with which various Agile champions in DC need to deal with might be stricter (due to security/confidentiality aspects of much of the development carried out in DC), but the underlying needs and dynamics are not really different from those in other cities in which Success Tour events were held.
Here is a sample of enlightening threads I listened to or participated in during the event:
- The business fabric has not quite caught up with Agile methods. In particular, Agile contracts are not yet where they need to be. The costs associated with “ECOing the contract” each time a change in requirements is made offset the methodical benefits of Agile. We need to find a way to “encode” Agile principles in contracts.
- In pitching software methods to their executives, Agile champions need to go beyond the benefits of Agile. Risk and risk mitigation are of equal importance. See The View from the Executive Suite for detailed guidance on the subject.
- The benefits of Agile have to be expressed in terms of the business of the business. One has to go beyond capturing “just” the operational benefits and address financial and business benefits. Peter Drucker’s famous quip “Companies make shoes!” applies. Click here for examination of the quip in the Agile context.
- Innovation through affordable experimentation is an Agile benefit that is under-represented in many discussions Agile champions hold. See the new edition of Jim Highsmith‘s Agile Project Management for an excellent discussion of this critical benefit.
- Agile is about uncertainty, not about complexity. To demonstrate the power of Agile, choose a project of high uncertainty. Complexity in such a project depends on your risk tolerance – it could be either low or high. Be aware that various issues related to complexity might manifest themselves on the surface as process issues. See Uncertainty, Complexity, Correctness for an in-depth discussion of the subject.
Next stops of the Agile Success Tour “train” are in Boston, Chicago, Seattle and London. Stay tuned…
We have Come a Long Way
I am involved these days in a bid to develop a suite of applications for a few inter-related data centers. There is nothing extraordinary about this bid. I have no doubt quite a few readers of his blog are routinely involved in similar undertakings.
Two stipulations, however, impressed me in the RFP:
- Explicitly stated preference for choosing a vendor who uses Agile methods.
- Requirement to have working code drops every week.
Both vendor preference and the working code requirement have been documented in writing as well as stated verbally in face-to-face meetings. Moreover, best I can tell most other stipulations in the RFP (other than the functional requirements and a clause about location of the team) are about characteristics of the operating environment in these data centers, not about how the “sausage” should be made.
I have been doing Agile since 2003. I do not recall seeing such Agile stipulation at the heart of routine RFPs.
Reflections on The Use of Agile Methods by the Entrepreneur
Walter Bodwell has posted his reflections on The Use of Agile Methods by the Entrepreneur. To quote Walter’s summary:
It looked at agile from a different point of view than typically done.
See here for the full review of the presentation by Walter.
The Use of Agile Methods by the Entrepreneur
Sebastian Hassinger and I just finished delivering this presentation in Agile Austin. It is a ‘think-piece’. Comments on the presentation will be highly appreciated.
Agile Contracts
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!
The Agile Executive 