The Agile Executive

Making Agile Work

Posts Tagged ‘Damon Edwards

OpsCamp Through an Internet-scale Lens

with 10 comments

OpsCamp Austin 2010

Like Agile Roots in Salt Lake City in June 2009, OpsCamp in Austin last week demonstrated how powerful grass roots conferences can be. We might not have had big names on the roster, but we sure had a productive dialog on the tricky issues lurking in the cusp between software development and IT operations in Cloud environments.

The conference has been amply covered by Michael Cote, John Willis, Mark Hinkle, and Damon Edwards (to name a few). This post restricts itself to commenting on one fundamental aspect of the cloud which IMHO does not get the attention it deserves. It might be implied in various discourses on the subject, but I believe it needs to be called out as a fundamental assumption for just about anything  and everything one might consider doing with respect to the cloud. I am referring to economies of scale.

As pointed out in a forthcoming book on Cloud Computing by colleague and friend Annie Shum, the cloud phenomenon is fundamentally driven by substantial economies of scale in very large data centers. The operational costs of running such data centers are close to an order of magnitude lower than these prevailing in small and mid-sized data centers. User benefits are primarily derived from these compelling economies of scale.

I will be asking Annie to write a detailed guest post on the subject for readers of The Agile Executive. Until her post is published here, I would recommend we primarily consider the Cloud as a phenomenon that only becomes meaningful at scale. In particular, Private Clouds are not likely to yield Internet-scale efficiencies. Folks who regard their company’s conventional data center as a private cloud might be missing up on the ‘secret sauce’ of cloud computing.

The various agile system administration schemes discussed at the Austin OpsCamp are essential to attaining the requisite economies of scale in cloud services. Watch out for follow-on OpsCamps in other cities for developments to come in this all important space.

The Tool is the Method

with 18 comments

In a recent post in dev2ops, Damon Edwards examines the role tools often play in the context of a desired cultural change. To quote Damon:

Did you ever notice that our first inclination is to reach for a tool when we want to change something? What we always seem to forget is that web operations, as a discipline, is only partially about technology.

Damon’s states the following view on the right balance to be struck:

The success of your web operations depends more on the processes and culture your people work within than it does on any specific tooling choices… We see this repeatedly in our consulting business. Time after time we are called in to do a specific automation project and wind up spending the bulk of the effort as counselors and coaches helping the organization make the cultural shift that was the real intention of the automation project.

While I am in full agreement with Damon on the phenomenon, I would like to highlight two nuances that in many cases make the tool is the method an effective approach to rolling Agile:

  1. The rise of professional procurers in Global 2000 companies (see Selling is Dead) changes transactional aspects of Agile engagements. Professional procurers typically focus on negotiating the best possible deal for the tool(s). Moreover, they tend to determine the preferred tool(s) in the early stages of negotiating the engagement.
  2. Tools might not change culture, but they can and often do change behavior. Think, for example,  about the way numerous folks use Twitter. What starts as “having a little bit of fun” often leads to major changes in the way one collects, stores, analyzes and assimilates information. The changes happen not due to an explicit intention to change, but as part of “playing” with Twitter.

Between these two nuances, a typical progression for an enterprise level Agile initiative tends to be as follows:

  • A tool is chosen
  • Teams start using the tool
  • The tool induces behavioral changes
  • These behavioral changes prevail, overshadowing cultural change initiatives

Hence, in many circumstances the tool indeed is the method. The chosen tool becomes a factor of the first order in determining not “only” how Agile (or any other software method) will be practiced, but what mindset will evolve in the course of the rollout.

See the presentation entitled  Four Principles, Four Cultures, One Mirror for additional details on the subject. A short summary of the presentation is given here. Related views are summarized by InfoQ here.

Written by israelgat

July 8, 2009 at 5:56 am