Many people over the years have discussed their distress with the religious tone that cloaks the implementation of Agile practices. Particularly from the testing side of the world, there is a lot of “should,” “should not,” and “can do better next time” dialogue that sounds more like a man trying to fix ethical lapses than a developer writing code. When I speak with adherents of test-driven development (TDD) in particular, there is a seeming non-comprehension that truly excellent, reliable code was ever developed prior to the advent of this one practice. I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than the a function of careful discipline and development rigor.The disconnect between today’s Agile view and earlier reality is equally evident in the wanton bashing of the waterfall model. To get any programmer today to adopt your recommendation, simply state that not doing so is just a new way of doing waterfall. Watch his toes curl despite never having used waterfall, nor seemingly having any awareness that it served the industry really well for decades. What, was everyone in that bygone era a fool?Alan Kay was entirely right when he said that programming today has become a pop culture: “Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future — it’s living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?”

It will pain some readers to know that the vast, error-free Internet predates Agile and even predates TDD. Crazy, right?

What I’m saying here is certainly not new. The fascination with today’s way of doing things and the view that it is the one true path to good code is a seemingly permanent part of the programming culture. But it has been greatly abetted by the legions of Agile consultants. By stressing the practices, they have corrupted what Agile was about. It’s important to remember that the Agile manifesto stated values, not practices. Immediately, though, values were translated into programming practices by consultants and, quickly, the former was lost. One of the original formulators of the manifesto, Dave Thomas, whom I interviewed this week, states his realization that a month after the manifesto was written it was already being corrupted: “…it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.”

What’s interesting in Thomas’s account is the view that Agile was a personal practice. Implicit is a personal way of orienting oneself towards a development process that accepts, even welcomes, change.

By pure coincidence, Allen Holub has been driving this point home in several blog posts, the most recent of which is a brilliant little piece that reminds us that Agile is a culture, not a set of practices. As he has previously explained, just because an organization is using scrum, doesn’t mean it’s Agile. He could have said the same thing about TDD, continuous integration, pair programming, or the like.

Whether a site is Agile or not depends on its culture. Does the culture support the personal values of the manifesto? If so, it’s Agile, if not, then it’s doing something else. So, indeed you could have a fully Agile site without TDD, continuous integration, or scrum. Likewise, you can have a site that uses all three practices, but cannot adapt to changes and is wholly inflexible in its work — so, not at all Agile. Yeah, I know, crazy, right?

Next: What the Agile Manifesto Really Said

———————————————————————————–

Source: Andrew Binstock, The Corruption of Agile, Dr. Dobbs Journal, March 18, 2014, http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698.

Andrew Binstock can be reached at alb@drdobbs.com or via Twitter at platypusguy