The Agile Executive

Making Agile Work

The System Assumes the System is Right

with 2 comments

The post It Won’t Work Here proposed tactics for dealing with a specific class of arguments why a company should not adopt Agile:

  • Uniqueness: “Some very unique elements exist in our company. These elements render industry data inapplicable.”
  • Secret sauce: “Something very special element existed in the companies reporting great success with Agile. Our company does not possess nor have access to the ‘secret sauce’ that enabled success elsewhere.”
  • Cultural change: “For the Agile initiative to succeed, our corporate culture needs to change. The required cultural change takes a lot of time and involves a great deal of pain. All in all, the risk of rolling Agile is unacceptably high.”
  • Affordability: “The company is strapped to the degree that investment in another software method is a luxury it can’t afford.”
  • Software is not core to us: “We are not a software company, nor is software engineering our core competency. Software is merely one of the many elements we use in our business.”

This posts augments It Won’t Work Here by shedding light on the reflexive behavior of the system the Agile champion is likely to run into while applying the recommended tactics.

The fundamental distinction the Agile champion needs to keep in mind is between individuals and organizations. To quote from Charles Perrow‘s work on the subject of complex organizations:

One cannot explain organizations by explaining the attitudes and behavior of individuals or even small groups within them. We learn a great deal about psychology and social psychology but little about organizations per se in this fashion.

To successfully function as an entity, an organization must assume that the system put in place to carry out its tasks is right. If the system is not right, the order and integration required for the proper functioning of the organization can’t be maintained. This assumption about being right tends to become all-inclusive. It is applied to both essential tasks and non-essential trivia.

The key to the success of Agile adoption in the face of the “system is right” reflex, is to budget your battles. As an Agile champion you fight only for things that are core to Agile methods, not for the myriad of contextual details about which the system assumes it is right.

For example, I would not spend a lot of energy on determining the unit of measure to be used in the Agile initiative. As an Agilist I prefer stories as the standard unit, e.g. release 2.0 was 500 stories while releases 3.0 constitutes 1,000 stories. But, I would accept lines of code or functions points as the standard unit of measure if the system so prefers.

Conversely, I would not accept system convictions when they violate core principles of Agile. For example, The Agile Triangle advocated by Jim Highsmith views scope, schedule and cost as constraints. This way of viewing Agile software is non-negotiable in my book. The reason for this strongly held conviction of mine is simple – the Agile initiative is likely to fail if the three (scope, schedule, cost) are considered as goals.

Source: based on Figure 1-3 in Jim Highsmith‘s Agile Project Management: Creating Innovative Products.

Advertisements

2 Responses

Subscribe to comments with RSS.

  1. Thanks for providing a thought-provoking angle from which to approach picking your battles, Israel. Here’s a link to a Jim Highsmith post with a little more detail on The Agile Triangle, in case any of your readers are interested.

    http://blog.cutter.com/2009/08/10/beyond-scope-schedule-and-cost-measuring-agile-performance/

    Kim Leonard

    January 25, 2010 at 7:55 am

    • Indeed, Both Jim’s post and the replies it triggered are well worth reading.

      Agile in my experience has a peculiar quality: it exposes deficits in adjacent domains. For example, poor technical or architectural decisions ultimately manifest themselves as process problems. When you examine the perceived process problems using the Agile lens, you often find the root cause is techno-architectural. Overly tight coupling of software components is a classical example.

      A similar phenomenon holds IMHO with respect to value. If you find it difficult to nail down value for the Agile Triangle, chances are some important elements are missing in the underlying business case.

      Israel

      israelgat

      January 25, 2010 at 11:05 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: