The Agile Executive

Making Agile Work

Posts Tagged ‘Sutherland

Confluence

with 3 comments

The approach Eric Ries advocates for the Agile start-up has been covered in previous posts (click here and here). Basically, Ries sees the need to iterate on the customer problem alongside iterating on the solution to the problem. Furthermore, a process of discovery – finding the customer – accompanies iterations on the problem and on the solution.

In a note today entitled Three Designing Bears, Kent Beck brings up a great example for the approach Ries promotes:

[JUnit] Max is a bootstrapped product, so I need to find revenue as quickly as possible. I have no idea what people might actually pay for in a testing tool, so I need to try things as quickly as possible. Features only need to be finished enough to give me reliable feedback about their value. Will people pay for features like those? If so, I can afford to finish them later.

Various other threads are quite relevant to and consistent with the ideas of Ries and Beck. For example, commenting on Flickr in The Art of Agile Development, James Shore highlights their speedy {code –> test –> stage –> deploy} cycle:

When a user posts a bug to the forum, the team can often fix the problem and deploy the new code to the live site within minutes.

When coupled with “real time” user feedback, the confluence of speedy development with fast deployment reduces the risk of developing features that are never or seldom used. It applies to both start-ups and established enterprises. It opens the door for new software business designs that would have been considered infeasible just a few years ago. For example, one could enhance the Marauder Strategy (“seek out slow ships and take them out”) proposed by Jeff Sutherland by competing not “only” on velocity of development, but on accelerated deployment cycles and ultra-fast feedback loops.

Advertisements

Written by israelgat

May 6, 2009 at 10:26 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.

Active Releases

with one comment

A Continuum

The traditional way of examining software from a life-cycle perspective is phase-by-phase. The software is developed; deployed; monitored; maintained; changed; and, eventually retired.

True though this description is, more and more executives these days actually view it all as one continuum. An application is developed, and  then deployed and maintained as part of some business process. At a certain level it might not really matter to a business executive what the software life-cycle is and which party carries out what phase. The thing that matters is that some service is performed to customer satisfaction. One could actually do complete  Business Process Outsourcing, chartering  a third party to take care of all the “headaches” in the continuum – from coding a critical software component to repairing a delivery truck to answering calls like, “My shipment has not arrived on the promised date.”

This post looks inside the continuum to comments on the implications of increasing the number of releases. Aspects related to, IT operationsIT service management and the customer as a strategic partner will be discussed in subsequent posts.

Number of Active Releases

The delivery of value to the customer is a fundamental tenet of Agile. The whole Agile development process is geared to that end. Customer value, however,  is realized when the customer is able to start using the product . As deployment cycles for enterprise software can be quite long, time gained through Agile development is not necessarily of immediate value to the customer. For customer value to materialize, the deployment cycle needs to be fast as well.

Companies that use Agile successfully can be quite different with respect to deployment practices. Here is a quick comparison of BMC Software, PatientKeeper and Google:

  • The successful implementation of Scrum at BMC Software led to producing 3-4 releases of the BMC Performance Manager per year.  However, time to deployment by various customers varied greatly.  Hence, a relatively small number of releases was active at any point in time.
  • With PatientKeeper,  Sutherland exploited the hyper-productivity of his Agile teams to produce a relatively large number of releases. When a customer needed a “release” it was downloaded via VPN and installed in fairly short order. Some 45 active releases of the software existed at any point in time.
  • Companies such as Google expedite deployment by using Software as a Service (SaaS) as the delivery mechanism. Google has only one actively deployed release at a time, but produces many fast releases.

As one increases the number of releases, a reasonable balance between velocity of development versus velocity of deployment in the continuum must be struck. To streamline end-to-end operations, velocity gains in one should be matched by gains in the other.

It does not Really Matter if you can Tell the Egg from the Chicken

One can speculate on how things evolve between development and deployment. Whether Agile software development leads to improvement in deployment, or Software as a Service “deployment” induces faster development processes. The Agile philosophy is well expressed in either case. In either direction, the slowere speed area is considered an opportunity, not a barrier. A Software as a Service Operations person who pushes for faster development speed lives the Agile philosophy even if he knows nothing about Agile methods.

Written by israelgat

February 10, 2009 at 2:58 pm

Can You Afford the Software You are Developing?

with 15 comments

A reader of The Agile Executive brought up some questions about product retirement in the context of  project teams that use Agile methods. For example: Should a product backed by a hyper-productive Agile project team be retired at the same point that an aging Waterfall product typically would?

The question is important. Customers can get very upset over the retirement of a product, particularly a mission-critical product. Even if the vendor offers a new product that replaces the one to be retired, the operational disruption associated with migrating to the new product is often troublesome. On the other hand, the cost of maintaining software, let alone keeping it current, could be and is often high for the enterprise software vendor.

The answer to the product retirement question ties Agile methods and practices to the fabric and economics of software engineering.  A good way to address the subject is to ask the following two questions:

  • Can you afford the software you are developing now?
  • Would you be able to continue to adequately invest in the software as it evolves down the road?

Rules of Thumb for Affordability

Affordability is, of course, in the eyes of the beholder. Your CFO might see it in quite differently than your CMO. To bring a discussion between the two, or any other forum of CXOs, to a common denominator, you need to get a handle on two numbers:

  • Development cost (including product management and test costs) per story card
  • Development cost as a percentage of product life-cycle cost

Development costs and life-cycle costs vary greatly from one company to another as well as within your company. For example:

  • Off-shore costs can be quite different from on-shore costs
  • The costs of maintaining high quality code are drastically different from those for average quality code. (See Estimating Software Costs by Capers Jones for a detailed analysis of the subject).
  • Productivity of an Agile team can easily eclipse that of a Waterfall team.

Laborious and time consuming that collecting good cost data across development methods, projects, sites and continents might be, you are essentially flying blindly with respect to affordability unless you have very specific cost data.

Until you gather this data, here are two rules of thumb that can be used to get a rough sense of  affordability:

  • A typical figure for development and test cost per story card for enterprise software project teams is thousands and thousands of dollars. It can exceed $10,000.  This (order of magnitude)  figure is for a contemporary software development and test organization in the US that is “reasonably” balanced between on-shore and off-shore development
  • Development cost is typically less than 50% of the total software life-cycle costs. Again, the assumption of reasonable balance between on-shore and off-shore applies

These rules of thumb should be used prudently. For example, Mens and Demeyer report cases in which software development costs constituted a mere 10% of the total life-cycle cost.

What is your Software Evolution Strategy?

In Program Evolution: Processes of Software Change, authors Lehman and Belady summarized years of research on the subject they and various collaborators carried out. Their bottom line is deceptively simple: software is live and always evolving. Furthermore, software decays.

Jim Highsmith uses the following great graph to demonstrate the effect of accrued technical debt on cost of change and responsiveness to customers:

in-can-you-afford-the-software-you-are-developing

Jim points out that no good option exists once the software has decayed to the point of excessive technical debt. Furthermore, once you are in the far right of curve estimation is next to impossible and afforability calculations become pretty useless. You might think about technical debt like debt on a credit card – you become a slave to servicing the debt instead of paying off the principal.

Affordability Revisited

Between the initial development cost and the cost of evolving and maintaining decaying software, many software development projects find themselves in dire need of higher productivity. Hence, a more precise statement of affordability is as follows:

  • Can you afford the software you are developing given your productivity during and after development of the first release?

The productivity results reported for companies successfully using Agile methods such as  BMC SoftwareSirsiDynix and Xebia indicate productivity gains of at least 2X, and often higher, compared to industry average. Everything else being equal you would be able to retire a product backed by a good Agile team later than a product backed by a Waterfall team.

Many Agile teams tend to be inclined to refactor the code on an on-going basis. For example, Salesforce devotes about 20% of development resources to refactoring. As a result, software decay is slower for such teams. They reach the point of no good options in Jim Highsmith’s graph later than teams who do not refactor the code day in and day out.

Refactoring is like flossing your teeth regularly. The dental tape disconnects your bank account from the dentist’s…

Written by israelgat

February 1, 2009 at 9:46 pm

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