autotelic, autistic, assonance-hole©.

“That’s Not Agile!” (You’re missing the point.)

It seems many Agile proponents are missing opportunities to help business and teams due to an increasingly strident insistence upon “Agile Method”. This, to me, is more than a little ironic; how can it be that there are so many who are so willing to be distinctly UN-Agile in relation to the use of Agile?

Frankly, “method” should be the very last noun to make the list when speaking of Agile; particularly as Agile is value-based rather than method-based and, thus, is more appropriately viewed through the lens of philosophy.

The entire discussion of Agile has rather “gone sideways” of late; for me, the key to getting things back on track is answering a simple question:

Is Agile a method or a philosophy?

If you ask most Agile adherents, they will tell you that Agile is a method; some may tell (after extensive discourse, and then, only reluctantly) that it is also a philosophy. Contrast this against the creators of Agile (e.g., Jim Highsmith, Martin Fowler, and Ken Schwaber, etc) who, from the moment of Agile’s presentation tell us it is both… and neither.

Business, of course, does not take well to mind-benders like this; the concept, frankly, is confusing if one is used to “method” being a strict set of rules and procedures, or when the idea of “philosophy in the workplace” just seems odd, or if there is any degree of perspective that “Agile is just some software development/technology thing”. This is, I think, the biggest hurdle that Agile must overcome if it wants to see improvement and traction in changing corporate culture. Indeed, given that the latest “State of Agile Development Survey” (page 10) sets corporate culture change as its biggest adoption impediment (52%), there isn’t a better time to take “That’s not Agile” off of the list of conversational responses. Getting over the idea that adoption must be a binary, “all or nothing” activity would, I think, go a long way.

Business culture is founded on values. This is a leverage point that is woefully under-utilized by Agile proponents. Consider: Just as any process or collection of processes by which one can accomplish a result to a certain level of consistency can be called a “method”, all methods of business operation are based upon value statements regarding what should be done, how it is most efficiently, productively done, and why this is the case. These value statements are the framework of the business philosophy and, as with anything in life, understanding the “why” of them is important.

In the same manner, getting business and work teams to adopt/use Agile generally doesn’t occur successfully until they can understand its values. As we know, the values of Agile resulted from iterations on Scrum and eXtreme Programming methods and was first set forth in via a succinct series of statements popularly known as the “Agile Manifesto”:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In reviewing this manifesto, several things are immediately clear (for all that most proponents of Agile today seem to be selectively blind to them):

  1. They clearly admit that there is value to all things mentioned.
  2. They clearly state that, as developers, they value the items on the left more.
  3. They clearly do not state that the items on the right could or even should be abandoned.
  4. They clearly do not state that those who are not developers could/should hold the same values.

In this crusade of “Agile as Method”, it seems many have forgotten that there is a difference between values (“what matters”) and principles (“what is Right”); more importantly, they have forgotten that Agile was defined primarily as a philosophy precisely in opposition of the obsessive focus on method as “silver bullet”.

The authors of the manifesto eloquently sustain this stance of “Agile as philosophy” in their attestation that the intent is to emphasize that philosophy (values) do not mandate method AND that the manifesto itself is inherently supportive of ALL methods exactly because its values are intended to be a check and balance OF method, as this quote in the history leading to the creation of the manifesto demonstrates:

The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.

In accord with the stated values, they deliberately chose not to create “their own method”; instead, they adopted some of the methods of Scrum and eXtreme Programming. Chief among these being the belief that “method” for its own sake is antithetical and, again, underscoring that values drive choice of method(s):

Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain “user stories”; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.

In this fashion, Agile is very much a “common sense” approach to getting things done. The natural response to discovering that a selected method or tool isn’t achieving the desired result is to change it (iterate, try something else, etc.).

The above is but one example of valuing results over methods. This neutrality in relation to method (and tools) is a key component of what makes Agile successful and gives us two important lessons:

It doesn’t matter what method you choose so long as it works.

It is important to be willing to mix and match across known methods to achieve the desired result.

So, the next time you find yourself faced with someone saying, “That’s not Agile!” remember that mandatory “method”, requisite form, or constraints of either are not the point – getting things done is the point. There is not a “method” that can be ascribed to Agile; but there are certain criteria one might use to assess the viability of a given method in conjunction with Agile:

  • Is it flexible?
  • Does it work?
  • Can we change it if it doesn’t work?

Succinctly, if it is agile, then it is Agile.

And to all of you who still utter, “That’s not Agile”, a wake-up call: You’re missing the point.